RFR(S): JDK-8232092 - Support for Windows drives created using subst

[Alan Bateman]

On 14/08/2020 18:29, Nhat Nguyen wrote:
> Hi nio-dev,
>
> I'm sending this email as a follow-up to a conversation on an issue with
> Windows's virtual drive:
>
> https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-July/067594.html
> https://bugs.openjdk.java.net/browse/JDK-8232092
>
> Since Alan pointed out that subst on Windows has never been fully supported by
> the Java's file system module, I have done some additional testing with Windows
> drives created using the subst command to see if we could identify other issues.
>
> The test covers some common operations provided by java.nio.file.Files such as
> creating, deleting, moving, copying, and creating symlinks of files in a virtual
> drive; these APIs internally call into the native Windows APIs defined under
> windows/native/libnio/fs/WindowsNativeDispatcher.c.
>
> Unfortunately, I could not find any additional failures other than the unexpected
> error code returned by GetVolumePathNameW causing Files.isWritable to produce
> incorrect results; this could be fixed by Nikola's changes.
>
> I understand that the test is by no means exhaustive and can miss other
> cases, so I would really appreciate any further guidance on what else to test.
>
> As a side note, the test contains three scenarios with symlinks which require
> Administrator privileges to run. I'm not sure how these tests are normally run
> using jtreg, so I decided to comment those out. Any suggestions are greatly
> appreciated as well.
>
> Webrev: http://cr.openjdk.java.net/~adityam/nhat/subst_drives/0/
>
If I recall correctly, the main issues we had with subst was toRealPath 
and sym links from NTFS volumes. I need to find my notes on this topic 
as I vaguely remember that fixing it would introduce inconsistencies. No 
objection to changing WindowsFileStore.create to check for 
ERROR_INVALID_PARAMETER but I'm not immediately confident that there are 
other issues lurking. The real we didn't add support originally is that 
we assumed that it was a legacy mechanism from DOS days.

The test will need a bit cleanup. It could easily be converted to a 
TestNG test if you want. Using Runtime.exec to run subst can be 
problematic and will need good testing to make sure that it is very 
reliable (if there is existing test infrastructure to read the 
input/error streams then we should probably use it as test forking 
processes/commands are often problematic). It would be good if the 
methods were comments. Also would be useful for future maintainer to 
avoid overly long times (side by side diffs are annoying when there are 
really long lines).

-Alan.