The build system Bazel maintains a file system API that provides a `statIfFound` function returning a file's attributes if it exists and null otherwise (https://github.com/bazelbuild/bazel/blob/ec36eacc31678ecf4b5c25f9ab7ab166330aff28/src/main/java/com/google/devtools/build/lib/vfs/FileSystem.java#L486). On Unix, this function is currently implemented via JNI since the overhead of an exception generated when the file is not found would be prohibitive. `FileSystemProvider.readAttributesIfExists` could be a way to avoid this overhead, but it suffers from the following issue:
For the file path "Test.java/foo" where Test.java is a regular file, on Linux and macOS, the following calls will throw FileSystemException: Test.java/foo: Not a directory instead of returning null:
Files.readAttributesIfExists(file, BasicFileAttributes.class);
Files.readAttributesIfExists(file, PosixFileAttributes.class);
SinceJDK-8356678, Files.exists and Files.notExists behave correctly on such paths.
For the file path "Test.java/foo" where Test.java is a regular file, on Linux and macOS, the following calls will throw FileSystemException: Test.java/foo: Not a directory instead of returning null:
Files.readAttributesIfExists(file, BasicFileAttributes.class);
Files.readAttributesIfExists(file, PosixFileAttributes.class);
Since
- relates to
-
JDK-8356678 (fs) Files.readAttributes should map ENOTDIR to NoSuchFileException where possible (unix)
-
- Resolved
-
- links to
-
Commit(master)
openjdk/jdk/2fbc4162
-
Review(master)
openjdk/jdk/29013