RFR: 8154364: Files.isSameFile() throws NoSuchFileException with broken symbolic links

[Alan Bateman]

On Tue, 12 Aug 2025 16:28:47 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> src/java.base/unix/classes/sun/nio/fs/UnixFileSystemProvider.java line 429:
>> 
>>> 427: 
>>> 428:         // neither exists, compare normalized paths without filesystem access
>>> 429:         return obj1.normalize().equals(obj2.normalize());
>> 
>> normalize is to deal with user input, I don't think we should be using it here.
>> 
>> (I will try to add review the changes soon but I'm concerned that this will require spec changes).
>
>> normalize is to deal with user input, I don't think we should be using it here.
> 
> This was intended to handle comparing paths with `..` and `.` like "a/b/c/../d/e" with "a/b/d/e" as there is no closer `Path` equivalent that I could see to `File.getCanonicalPath` that does not access the file system, i.e., to avoid `Path.toRealPath` and a consequent `NoSuchFileException`.

normalize collapses the path so I'm concerned about foo/.. in one and bar/.. in the other.  They may collapse down to the equal paths, which may not be the right answer.

I think the approach of collecting the file keys along the chain is good, a match means the method can return true. Also the case where one exists and the other doesn't is good. Beyond that then I think the method will have to throw as it can't give an answer.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26736#discussion_r2273903738