RFR: 8252971: WindowsFileAttributes does not know about Unix domain sockets [v2]

[Alan Bateman]

On Fri, 5 Feb 2021 22:28:10 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

>> Could I get the following change reviewed please? It fixes a problem (in JEP380) on Windows where some file operations on Unix domain sockets were not working and led to the feature being disabled on Windows 2019 Server in JDK 16. So, the fix re-enables the feature on all versions of Windows that support it.
>> 
>> The test checks all the file APIs that were affected by the problem. The change touches the code that handles symbolic links in Windows (since they are implemented as NTFS reparse points, like Unix sockets), but I didn't add any specific testing in this area, as I assume the existing unit tests for NIO symbolic links should cover that. If I should add more tests here, then I can do that.
>> 
>> Thanks,
>> Michael
>
> Michael McMahon has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains ten additional commits since the last revision:
> 
>  - Merge branch 'master' into 8252971-socket-attributes
>  - update
>  - update
>  - update
>  - update
>  - update after Alan's first review
>  - Merge branch 'master' into 8252971-socket-attributes
>  - test update
>  - initial fix for review

The changes are a bit disruptive but I agree are necessary to improve the experience when socket files are encountered on the file system. I have focused on the changes to the implementation, I see Daniel is focused on the test so I only lightly skimmed that.

src/java.base/windows/classes/sun/nio/fs/WindowsFileSystemProvider.java line 344:

> 342:                                 Set.of(WindowsChannelFactory.OPEN_REPARSE_POINT),
> 343:                                 0L);
> 344:                     fc.close();

checkAccess follows sym links and I wonder if there is any scenario where ERROR_CANT_ACCESS_FILE can be returned when respare point rather than the target cannot be accessed. This may be something the Microsoft folks can comment on.

Minor nit is the params to newFileChannel is are mis-aligned now.

src/java.base/windows/classes/sun/nio/fs/WindowsPath.java line 866:

> 864: 
> 865:         try {
> 866:             // needs one additional flag to open a Unix domain socket

The comment here is confusing as there are two flags.

src/java.base/windows/classes/sun/nio/fs/WindowsPath.java line 859:

> 857: 
> 858:     /**
> 859:      * returns INVALID_HANDLE_VALUE if path is not a socket

Can you change this to "Returns".

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

PR: https://git.openjdk.java.net/jdk/pull/2424