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

[Alan Bateman]

On Sat, 6 Feb 2021 20:41:38 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

>> 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.
>
> Though looking at that piece of code, I think its purpose would be clearer if it were put in a separate method with a name that shows were trying to open it as a socket.

Moving it to a separate method would make it easier to maintain and discuss here but I would really prefer if it checked the reparse tag and re-throw the original exception if the tag is IO_REPARSE_TAG_SYMLINK. That way it wouldn't get tripped up by ERROR_CANT_ACCESS_FILE being thrown for other reasons, e.g. sym link -> sym link -> target where an intermediate sym link can't be accessed.

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

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