RFR: 8315273: (fs) Path.toRealPath(LinkOption.NOFOLLOW_LINKS) fails when "../../" follows a link (win) [v5]

[Brian Burkhalter]

On Thu, 12 Sep 2024 07:58:21 GMT, Daniel Jeliński <djelinski at openjdk.org> wrote:

> Based on the above, I think the current `toRealPath` implementation on Windows is doing just fine, only the `ToRealPath` test needs to be fixed.

Based on these comments in [WindowsPath](https://github.com/openjdk/jdk/blob/81ff91ef27a6a856ae2c453a9a9b8333b91da3ab/src/java.base/windows/classes/sun/nio/fs/WindowsPath.java#L202)

        // Long paths need to have "." and ".." removed and be prefixed with
        // "\?". Note that it is okay to remove ".." even when it follows
        // a link - for example, it is okay for foo/link/../bar to be changed
        // to foo/bar. The reason is that Win32 APIs to access foo/link/../bar
        // will access foo/bar anyway (which differs to Unix systems)

it seems safe to say that the current `toRealPath()` implementation is, as you say, all right as is. If these comments are correct, then it appears that on Unix the `link` in `foo/link/../bar` would first be resolved and then the `..` would be removed along with the element preceding it, but on Windows, `link` is just treated as a name element without resolution and is summarily removed along with `..`. This is consistent with the `Files.createFile(Path.of("link/../../file"))` example I posted above.

> [...] only the `ToRealPath` test needs to be fixed.
> 
> As far as I could tell, `Path.toRealPath` does not make any promises about what the resulting path should be. The only requirement is that the path should refer to the same file, so the current implementation does not violate the spec.

At this point, I tend to agree.

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

PR Comment: https://git.openjdk.org/jdk/pull/15525#issuecomment-2347307267
PR Comment: https://git.openjdk.org/jdk/pull/15525#issuecomment-2347308341