RFR: 8368156: java/nio/file/Files/IsSameFile.java failing (win) [v2]

[Brian Burkhalter]

On Tue, 23 Sep 2025 08:59:15 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>>> Hello Brian, this returns a collection which contains a `Path` that is obtained from a `FileSystem` that gets closed before the `Path` is used in the test method. Looking at the specification of `FileSystem.getPath()` I don't see any text which states the behaviour of `Path` instances after the `FileSystem` has been closed.
>> 
>> The FileSystem class description does specify: "Once closed, any further attempt to access objects in the file system cause ClosedFileSystemException to be thrown". I don't have time right now to check that the zip file system adheres to this.
>
> Hello Alan,
> 
>> I don't have time right now to check that the zip file system adheres to this.
> 
> I did a quick check. Not all methods on `Path` returned by the ZIP filesystem, adhere to this specification. For example, `toURI()`, `toAbsolutePath()`, `relativize()` all return normally even after the ZIP file system is closed. Whereas, `toRealPath()` throws `ClosedFileSystemException`:
> 
> 
> jshell> var fs = FileSystems.newFileSystem(java.net.URI.create("jar:file:///tmp/foo.jar"), Map.of())
> fs ==> /tmp/foo.jar
> 
> jshell> var p = fs.getPath("/");
> p ==> /
> 
> jshell> fs.close()
> 
> jshell> var _ = p.toAbsolutePath()
>  ==> /
> 
> jshell> var _ = p.toUri()
>  ==> jar:file:///tmp/foo.jar!/
> 
> jshell> var _ = p.relativize(p)
>  ==> 
> 
> jshell> var _ = p.toRealPath()
> |  Exception java.nio.file.ClosedFileSystemException
> |        at ZipFileSystem.ensureOpen (ZipFileSystem.java:1843)
> |        at ZipFileSystem.checkAccess (ZipFileSystem.java:584)
> |        at ZipPath.checkAccess (ZipPath.java:885)
> |        at ZipPath.toRealPath (ZipPath.java:176)
> |        at ZipPath.toRealPath (ZipPath.java:56)
> |        at do_it$Aux (#4:1)
> |        at (#4:1)
> 
> I haven't yet checked other object types returned by the ZipFileSystem, but it does look like it will need some updates to adhere to the specification. I'll take a deeper look and track this separately.

Code refactored to eliminated any such eventuality in 7ace52e.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27440#discussion_r2372810549