8355342: File.getCanonicalPath on Java 24 resolves paths on network drives to UNC format

[bplb]

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.

---

Progress

• Change must be properly reviewed (1 review required, with at least 1 Reviewer)
• Change must not contain extraneous whitespace
• Commit message must refer to an issue

Issue

• JDK-8355342: File.getCanonicalPath on Java 24 resolves paths on network drives to UNC format (Bug - P3)

Reviewing

Using git

Checkout this PR locally:
$ git fetch https://git.openjdk.org/jdk.git pull/27324/head:pull/27324
$ git checkout pull/27324

Update a local copy of the PR:
$ git checkout pull/27324
$ git pull https://git.openjdk.org/jdk.git pull/27324/head

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 27324

View PR using the GUI difftool:
$ git pr show -t 27324

Using diff file

Download this PR as a diff file:
https://git.openjdk.org/jdk/pull/27324.diff

Using Webrev

Link to Webrev Comment

[bridgekeeper]

👋 Welcome back bpb! A progress list of the required criteria for merging this PR into master will be added to the body of your pull request. There are additional pull request commands available for use with this pull request.

[openjdk]

❗ This change is not yet ready to be integrated.
See the Progress checklist in the description for automated requirements.

[openjdk]

@bplb The following label will be automatically applied to this pull request:

• core-libs

When this pull request is ready to be reviewed, an "RFR" email will be sent to the corresponding mailing list. If you would like to change these labels, use the /label pull request command.

[mlbridge]

Webrevs

• 03: Full - Incremental (0f29a4f3)
• 02: Full - Incremental (833ec725)
• 01: Full - Incremental (8e93980c)
• 00: Full (a3a7c10e)

[AlanBateman]

Would it be possible to provide a summary as to why we don't run into this with toRealPath?

[bplb]

In toRealPath, the function GetFinalPathNameByHandle is not invoked unless links are being followed and a reparse point is encountered. Otherwise the real path is built up by analyzing the input path. I had actually already been wondering whether the canonicalized path should be checked for links before invoking getFinalPath.

[AlanBateman]

I had actually already been wondering whether the canonicalized path should be checked for links before invoking getFinalPath.

I assume you've checked the flags that can be provided to GetFinalPathNameByHandleW and that there isn't a solution there. In that case, I think it would be better to check the attributes in the WIN32_FIND_DATA to see if it's a reparse point. That would mean deeper changes but should mean you avoid the post-processing the result from getFinalPath, which I think is a bit too hacky to have in this code.

[bplb]

I assume you've checked the flags that can be provided to GetFinalPathNameByHandleW and that there isn't a solution there.

Yes, I checked all combinations before pursuing this change. There's no help there.

In that case, I think it would be better to check the attributes in the WIN32_FIND_DATA to see if it's a reparse point. That would mean deeper changes

Will check it out.

but should mean you avoid the post-processing the result from getFinalPath, which I think is a bit too hacky to have in this code.

I think it's correct but I agree about its "hackiness."

[bplb]

Would it be possible to provide a summary as to why we don't run into this with toRealPath?

In toRealPath, the function GetFinalPathNameByHandle is not invoked unless links are being followed and a reparse point is encountered.

In this scenario

 Directory of Z:\

09/17/2025  03:39 PM    <DIR>          .
09/17/2025  08:36 AM    <SYMLINK>      link [target.txt]
09/10/2025  04:41 PM                18 target.txt

where Z: is mapped as net use Z: \\localhost\c$\Temp, in other words to C:\Temp, a similar problem happens with toRealPath:

jshell> Path.of("Z:\\target.txt").toRealPath()
$7 ==> Z:\target.txt

jshell> Path.of("Z:\\link").toRealPath()
$8 ==> \\localhost\c$\Temp\target.txt