Paths starting with "//?/" on Windows are local

[Torbjorn-Svensson]

The prefix might be used to support paths longer than MAX_PATH.
https://learn.microsoft.com/en-us/windows/win32/fileio/naming-a-file#win32-file-namespaces

[github-actions]

Test Results

   25 files  ±0     25 suites  ±0   11m 19s ⏱️ +34s
2 156 tests ±0  2 110 ✅ ±0  46 💤 ±0  0 ❌ ±0 
2 200 runs  ±0  2 154 ✅ ±0  46 💤 ±0  0 ❌ ±0 

Results for commit f08103b. ± Comparison against base commit e2267e3.

♻️ This comment has been updated with latest results.

[HannesWell]

This change makes the Path constructor handle //?/, but I wonder shouldn't the //?/ prefix be stored somehow in order to make it available when the file-system is queried eventually?
But adding it to the device is probably not the right thing to do.

[Torbjorn-Svensson]

This change makes the Path constructor handle //?/, but I wonder shouldn't the //?/ prefix be stored somehow in order to make it available when the file-system is queried eventually?
But adding it to the device is probably not the right thing to do.

Adding it to the device is not the correct thing to do and I'm not sure if it makes sense to save it.
The main use for it, as far as I know, is to avoid the MAX_PATH length limitation. I suppose the JVM is already doing something along these lines internally, as my testing shows that java applications does not have problem of managing deep file trees.

[Torbjorn-Svensson]

Rebased PR on 1d9eb47.
Anything I need to do prior to getting this merged?

[vogella]

@HannesWell any more concerns or can this be merged?

[HannesWell]

Sorry for the late reply.

This change makes the Path constructor handle //?/, but I wonder shouldn't the //?/ prefix be stored somehow in order to make it available when the file-system is queried eventually?
But adding it to the device is probably not the right thing to do.

Adding it to the device is not the correct thing to do and I'm not sure if it makes sense to save it. The main use for it, as far as I know, is to avoid the MAX_PATH length limitation. I suppose the JVM is already doing something along these lines internally, as my testing shows that java applications does not have problem of managing deep file trees.

That's right. I tested it and with the standard Java File or Path API one can handle files and directories straight forward without that prefix (unlike for example the explorer). So it does not need to be added. And with JDK22 Java will also strip it off:
https://jdk.java.net/22/release-notes#JDK-8287843

So in general this change is fine, only the test should be slightly adjusted.

[HannesWell]

Looks all good now.
Thank you for this contribution.