Bug #5839
closed![Author: Martin Honnen](https://www.gravatar.com/avatar/3ea75023c3c487f36257090d420b7c50?rating=PG&size=50&default=https%3A%2F%2Fassets.plan.io%2Fimages%2Fdefault_avatar.png)
SaxonCS.exe query -qs doesn't find file in local working directory: FODC0002 Exception thrown by URIResolver
100%
Description
Testing on Windows, I can run e.g. Saxon HE Java fine from the command line with -qs:"'cars-example-json-as-xml.xml' => doc() => xml-to-json()"
, it finds the local file cars-example-json-as-xml.xml
fine.
SaxonCS (tested with both 11 and 12), however fails, looking for a file file:///C:/Users/marti/OneDrive/Documents/xslt/blog-xslt-3-by-example/xml-to-json/file:/C:/Users/marti/OneDrive/Documents/xslt/blog-xslt-3-by-example/xml-to-json
:
'C:\Program Files\Saxonica\SaxonCS-12.0\SaxonCS.exe' query -t -qs:"'cars-example-json-as-xml.xml' => doc() => xml-to-json()"
SaxonCS-EE 12.0 from Saxonica
.NET 6.0.10 on Windows 10.0.22621.0
Using license serial number V..
..
Analyzing query from {'cars-example-json-as-xml.xml' => doc() => xml-to-json()}
Analysis time: 18.4502 milliseconds
Error on line 1 column 1 of xml-to-json:
FODC0002 Exception thrown by URIResolver resolving `cars-example-json-as-xml.xml` against
`file:///C:/Users/marti/OneDrive/Documents/xslt/blog-xslt-3-by-example/xml-to-json/file:/C:/Users/marti/OneDrive/Documents/xslt/blog-xslt-3-by-example/xml-to-json'
at Microsoft.Win32.SafeHandles.SafeFileHandle.CreateFile(String fullPath, FileMode mode, FileAccess access, FileShare share, FileOptions options)
at Microsoft.Win32.SafeHandles.SafeFileHandle.Open(String fullPath, FileMode mode, FileAccess access, FileShare share, FileOptions options, Int64 preallocationSize)
at System.IO.Strategies.OSFileStreamStrategy..ctor(String path, FileMode mode, FileAccess access, FileShare share, FileOptions options, Int64 preallocationSize)
at System.IO.Strategies.FileStreamHelpers.ChooseStrategyCore(String path, FileMode mode, FileAccess access, FileShare share, FileOptions options, Int64 preallocationSize)
at System.IO.Strategies.FileStreamHelpers.ChooseStrategy(FileStream fileStream, String path, FileMode mode, FileAccess access, FileShare share, Int32 bufferSize, FileOptions options, Int64 preallocationSize)
at System.IO.File.OpenRead(String path)
at Org.XmlResolver.Utils.UriUtils._getFileStream(String uri)
at Org.XmlResolver.Utils.UriUtils.GetStream(String uri, Assembly asm)
at Org.XmlResolver.Utils.UriUtils.GetStream(Uri uri)
at Saxon.Callbacks.DirectResourceResolver.resolve(JJ_ResourceRequest request)
at Saxon.Hej.lib.JJ_ResourceRequest.resolve(JJ_ResourceResolver[] resolvers)
at Saxon.Hej.functions.DocumentFn.resolveURI(String href, String baseURI, String documentKey, XPathContext context)
: Die Syntax für den Dateinamen, Verzeichnisnamen oder die Datenträgerbezeichnung ist falsch. : 'C:\Users\marti\OneDrive\Documents\xslt\blog-xslt-3-by-example\xml-to-json\file:\C:\Users\marti\OneDrive\Documents\xslt\blog-xslt-3-by-example\cars-example-json-as-xml.xml'
<?xml version="1.0" encoding="UTF-8"?>Query processing failed: Exception thrown by URIResolver resolving `cars-example-json-as-xml.xml` against `file:///C:/Users/marti/OneDrive/Documents/xslt/blog-xslt-3-by-example/xml-to-json/file:/C:/Users/marti/OneDrive/Documents/xslt/blog-xslt-3-by-example/xml-to-json': Die Syntax für den Dateinamen, Verzeichnisnamen oder die Datenträgerbezeichnung ist falsch. : 'C:\Users\marti\OneDrive\Documents\xslt\blog-xslt-3-by-example\xml-to-json\file:\C:\Users\marti\OneDrive\Documents\xslt\blog-xslt-3-by-example\cars-example-json-as-xml.xml'
Exiting with code 2
That seems a bug to me.
Updated by Martin Honnen over 1 year ago
For what it's worth, the old C:\Program Files\Saxonica\SaxonHE10.8N\bin\Query.exe
does manage to execute such a -qs
argument.
Updated by Martin Honnen over 1 year ago
SaxonCS 12 also doesn't find a file in the local working directory on Linux:
mh@LibertyDell:~$ ls *.xml
foo.xml
mh@LibertyDell:~$ SaxonCS-12.0/SaxonCS query -t -qs:"doc('foo.xml')"
SaxonCS-EE 12.0 from Saxonica
.NET 6.0.13 on Linux
Using license serial number V..
..
Analyzing query from {doc('foo.xml')}
Analysis time: 26.680069 milliseconds
Error on line 1 column 5 of mh:
FODC0002 Unable to retrieve URI file:///home/mh/file:/home/foo.xml
<?xml version="1.0" encoding="UTF-8"?>Query processing failed: Unable to retrieve URI file:///home/mh/file:/home/foo.xml
Exiting with code 2
Updated by Norm Tovey-Walsh over 1 year ago
This and the other bug point pretty clearly at URI resolution not happening correctly.
Updated by Martin Honnen over 1 year ago
The bug with URI resolution must be in the transpiled code I don't have access to (other than using DotnetPeek or similar), when I use Saxon.Api e.g.
[Test]
public void DocTest()
{
var xqueryCompiler = processor.NewXQueryCompiler();
xqueryCompiler.BaseUri = new Uri(Path.Combine(Environment.CurrentDirectory, "foo.xml"));
var xqueryExecutable = xqueryCompiler.Compile("'sample1.xml' => doc()");
var result = (XdmNode)xqueryExecutable.Load().EvaluateSingle();
Assert.IsNotNull(result);
}
all works out.
Updated by Michael Kay over 1 year ago
I think the root cause of the problem is that the C# emulation of java.lang.System.getProperty("user.dir")
is returning file:///Users/user/dir/
rather than /Users/user/dir
.
Unfortunately it's not enough simply to fix this, because there are code paths that rely on the incorrect value...
Updated by Michael Kay over 1 year ago
- Status changed from New to Resolved
- Applies to branch 11, 12, trunk added
- Fix Committed on Branch 11, 12, trunk added
I'm changing the C# version of System.getProperty("user.dir") to return the same as the Java version, and I'll then work through the consequences...
The first consequence is that if the current directory is /Users/jim/Desktop/temp
, it's trying to retrieve /Users/jim/Desktop/books.xml
rather than /Users/jim/Desktop/temp/books.xml
.
Most paths that use the current working directory appear to go via Transform.getCurrentWorkingDirectory() which returns a URI; on SaxonCS this is implemented as "return Saxon.Ejava.io.File.CurrentDirectoryUri();", so I shall try to use that method throughout. Moving it to CommandLineOptions as this seems more neutral.
Note, the patches affect SaxonJ although the problem is observed only on SaxonCS.
Updated by O'Neil Delpratt over 1 year ago
- % Done changed from 0 to 100
- Fixed in Maintenance Release 11.5 added
Bug fix applied in the Saxon 11.5 maintenance release.
Updated by O'Neil Delpratt over 1 year ago
- Status changed from Resolved to Closed
- Fixed in Maintenance Release 12.1 added
Bug fix applied in the Saxon 12.1 maintenance release.
Please register to edit this issue