On Fri, 17 Oct 2025 22:54:17 GMT, Brian Burkhalter <[email protected]> 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
