Eryk Sun <eryk...@gmail.com> added the comment:

> I really want a fix for this in 3.8, or else os.stat(sys.executable) 
> may fail

I agree, but Python can support this without handling junctions as symlinks or 
limiting the reparse points that we can follow. There are reparse points for 
offline storage and projected file systems (e.g. VFS for Git) that should 
normally be traversed, and to that I would add junctions. stat() in Unix always 
opens a mounted directory, not the underlying directory of a mount point. 
Windows Python should try to be consistent with Unix where doing so is 
reasonable. 

Given the only option here is follow_symlinks, then the first CreateFileW call 
in win32_xstat_impl should only open a reparse point if follow_symlinks is 
false. In this case, if it happens to open a reparse point that's not a 
symlink, it should try to reopen with reparsing enabled. In either case, if 
reparsing fails because a reparse point isn't handled (ERROR_CANT_ACCESS_FILE), 
try to open the reparse point itself. The latter would be the second open 
attempt if follow_symlinks is true and the third open attempt if 
follow_symlinks is false. 

If a reparse point isn't handled, then there's nothing in principle that stat() 
could ever follow. Given that it's impractical to fail in this case, 
considering how much code would have to be modified, then the above compromise 
should suffice.

I checked RtlNtStatusToDosError over the range 0xC000_0000 - 0xC0ED_FFFF. (In 
ntstatus.h, FACILITY_MAXIMUM_VALUE is 0xED, so there's no point in checking 
facilities 0x0EF-0xFFF.) Only STATUS_IO_REPARSE_TAG_NOT_HANDLED maps to 
ERROR_CANT_ACCESS_FILE, so we don't have to worry about unrelated failures 
using this error code. This is separate from an invalid reparse point 
(ERROR_INVALID_REPARSE_DATA) or a reparse point that can't be resolved 
(ERROR_CANT_RESOLVE_FILENAME), which should still be errors that fail the call.

----------

_______________________________________
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue37834>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Reply via email to