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

[Michael McMahon]

On Sat, 6 Feb 2021 17:09:11 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> 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
>
> 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.

So, if the reparse point is a symbolic link, and if the target of the link does not exist, then  ERROR_FILE_NOT_FOUND is returned. I've tested and confirmed this. It's also what you would expect because you would expect usage of symbolic links to be transparent and the same error code to be returned as when traversing a path and some element of the path does not exist, or isn't accessible.

>From what I can see ERROR_CANT_ACCESS_FILE can be returned for other reasons such as file corruption, which I think would be likely to return the same error again the second time.

I've also done some manual testing of other kinds of reparse point (junctions and mount points) and have tried various "target not existing" type of scenarios and ERROR_CANT_ACCESS_FILE is never returned.

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

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