RFR: 8355342: File.getCanonicalPath on Java 24 resolves paths on network drives to UNC format [v6]

[Alan Bateman]

On Fri, 17 Oct 2025 22:54:17 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> `File.getCanonicalPath` invokes `GetFinalPathNameByHandle` on the result of `canonicalize0` which causes the drive letter of a mapped drive to be converted to a UNC prefix. If such a substitution is detected, this request proposes to revert the conversion of drive letter to UNC prefix before returning the canonical path.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8355342: Do not check for backslash as third character of input pathname string

> Commit [ebe88f7](https://github.com/openjdk/jdk/commit/ebe88f7347f0cf84c9aabf6cbecce23a53fd20d6) changes `WinNTFileSystem::canonicalize` to fall back to the result of `canonicalize0` if `getFinalPath` converts a drive letter + `:` to a path beginning with `\`. I have investigated and tested various Windows API functions and there does not appear to be a way to determine to exactly which path prefix a drive letter will be mapped by `GetFinalPathNameByHandleW`.

Would it be possible to paste in the outcome from the latest change with files that exist, and do not exist, on the UNC share. I think it would be useful to have both the toRealPath and File.getCanonicalPath outcome. This is a tricky issue as the current implementation isn't wrong, it's just surprising (and in the case of the bug report, awkward when attempting to use the real path as a working directory for a subprocess).

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

PR Comment: https://git.openjdk.org/jdk/pull/27324#issuecomment-3419389018