Cannot resolve FileSystem root resource in Native Image

[bclozel]

Describe the issue
When adding resources to the native image, the native image FileSystemProvider is used to resolve resources at runtime. The root directory of this file system is not available; this prevents applications from listing all available resources in the application.
This is being extracted from #1108, which conflates several issues.

Steps to reproduce the issue
Please include both build steps as well as run steps

1. git clone git@github.com:bclozel/native-resources.git
2. ./gradlew nativeCompile

Describe GraalVM and your environment:

java -version
openjdk version "17.0.4" 2022-07-19
OpenJDK Runtime Environment GraalVM CE 22.2.0 (build 17.0.4+8-jvmci-22.2-b06)
OpenJDK 64-Bit Server VM GraalVM CE 22.2.0 (build 17.0.4+8-jvmci-22.2-b06, mixed mode, sharing)

• CE 22.2.0
• JDK major version: 17
• OS: macOS Monterey
• Architecture: AMD64

The repo README explains how to reproduce the behavior step by step.

Please tag this issue with the "Spring" tag.

[jovanstevanovic]

Since you have permission, could you assign this issue to me? (and close #1108)

[bclozel]

@jovanstevanovic Sorry I don't have permission on this repository. I think the labels were added automatically by the GitHub issue template.

[bclozel]

I've updated my sample with a different yet related problem - how slashes are dealt with when walking the filesystem. I can create a different issue for this if you think this is a different problem; I'm not just familiar with this area, see this section.

[sbrannen]

@bclozel, doesn't it also fail if you run your example with /first or /first/ (leading slash)?

I believe the issue is that java.nio.file.FileSystem.getPath(String, String...) in the native image implementation does not clean the resulting path.

For example, when using the OS file system on a Mac, you can supply a trailing slash (first/), any number of leading slashes (/first, /////first), or a combination of both (///first/), and the standard FileSystem always returns /first as the path within the file system.

So it appears to be twofold:

• FileSystem.getPath does not clean the resulting path with regard to leading and trailing slashes.
• FileSystem.walk fails to find anything if the supplied Path has a leading or trailing slash.

[bclozel]

@sbrannen No it doesn't fail in my sample

./build/native/nativeCompile/native-resources resource:/// /first
Sep 26, 2022 4:59:04 PM org.example.Main main
INFO: scheme: resource:///, root: /first
Sep 26, 2022 4:59:04 PM org.example.Main lambda$main$0
INFO: root directory: /
Sep 26, 2022 4:59:04 PM org.example.Main lambda$main$1
INFO: |- /first
Sep 26, 2022 4:59:04 PM org.example.Main lambda$main$1
INFO: |- /first/first.txt

It also works with the following:

./build/native/nativeCompile/native-resources resource:/// ////first///first.txt
Sep 26, 2022 5:00:29 PM org.example.Main main
INFO: scheme: resource:///, root: ////first///first.txt
Sep 26, 2022 5:00:29 PM org.example.Main lambda$main$0
INFO: root directory: /
Sep 26, 2022 5:00:29 PM org.example.Main lambda$main$1
INFO: |- /first/first.txt

Maybe this is something related to how the API is being used in Framework vs. in my sample?

[sbrannen]

OK. Thanks for checking. I'll get back to you if I come up with anything else definitive.

[sbrannen]

If you get a Path from the empty string "" with the native image FileSystem (fileSystem.getPath("")) and then invoke resolve(...) on that Path, you get the following exception.

java.lang.ArrayIndexOutOfBoundsException: Index -1 out of bounds for length 0
       com.oracle.svm.core.jdk.resources.NativeImageResourcePath.resolve(NativeImageResourcePath.java:302)
       com.oracle.svm.core.jdk.resources.NativeImageResourcePath.resolve(NativeImageResourcePath.java:327)

Whereas, a Path created by the standard OS FileSystem does not throw an exception in that scenario.

[jovanstevanovic]

The fix for root path resolution is on the merge queue.

Regarding trailing slashes and empty strings, I would suggest not merging them as a part of this issue, so please derivate all edge cases in separate GH issue(s), and I'll take a look afterward.

@sbrannen What is the output (return value) in OS FileSystem with an empty string as an argument? OOB exception is undoubtedly not something that you expect.

[sbrannen]

What is the output (return value) in OS FileSystem with an empty string as an argument? OOB exception is undoubtedly not something that you expect.

System.out.println("FileSystems.getDefault().getPath(\"\"): [%s]".formatted(FileSystems.getDefault().getPath("")));
System.out.println("FileSystems.getDefault().getPath(\"\").resolve(\"test\"): [%s]".formatted(FileSystems.getDefault().getPath("").resolve("test")));

Prints:

FileSystems.getDefault().getPath(""): []
FileSystems.getDefault().getPath("").resolve("test"): [test]

In the following line of code...

graal/substratevm/src/com.oracle.svm.core/src/com/oracle/svm/core/jdk/resources/NativeImageResourcePath.java

Line 302 in 3950e04

if (p1.path[p1.path.length - 1] == '/') {

... if p1.path.length is 0, then you get the ArrayIndexOutOfBoundsException.

[bclozel]

Thanks @jovanstevanovic I've created #5080 to address #5020 (comment)

@sbrannen Could you create a separate issue for the behavior you're describing? This issue is going to be closed when the merge goes in.

[sbrannen]

Could you create a separate issue for the behavior you're describing? This issue is going to be closed when the merge goes in.

I raised #5081 to address that.

[jovanstevanovic]

Fix is on a master.

[sdeleuze]

Could you please make sure it is backported to release/graal-vm/22.3 and update the milestone of this issue accordingly?

[jovanstevanovic]

@sdeleuze Yes, I'm trying to backport it now.