On Sat, 6 Feb 2021 20:35:58 GMT, Michael McMahon <micha...@openjdk.org> wrote:
>> 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. 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. ------------- PR: https://git.openjdk.java.net/jdk/pull/2424
