Eryk Sun <> added the comment:

Yes, it makes sense to call GetFileAttributes as the fast path, and then fall 
back on a slow path (i.e. create, query, close) for a directory reparse point. 
With GetFileInformationByHandleEx, the equivalent query is FileBasicInfo, which 
is available starting with Vista, so this could be backported to 3.5 if 

However, to be more consistent with POSIX, we need to first query 
FileAttributeTagInfo on the reparse point to get the reparse tag. If it's 
IO_REPARSE_TAG_MOUNT_POINT (junction) and the target is a volume name (i.e. 
"Volume{GUID}"), then we should return true. This can also be checked via 
GetVolumePathName, after normalizing the path, like how os.path.ismount() works 
on Windows ( A mount point is always a directory, even if the volume 
isn't currently available. OTOH, sometimes junctions are used as links instead, 
which is being addressed more generally by Vidar Fauske in issue 31226. There's 
potentially overlap here with Vidar's proposed _Py_is_reparse_link function.

More info on GetFileAttributes, if you're curious:

GetFileAttributes and GetFileAttributesEx are relatively cheap I/O calls. 
They're implemented by translating to a native NT path and calling 
NtQueryAttributesFile and NtQueryFullAttributesFile, respectively. These two 
system calls are optimized for network access. They use an open packet that 
that's query-only without reparsing. The I/O Manager's parse routine can thus 
use a local (fake) File object, the file system's corresponding fast I/O 
routine, and skip the normal cruft of working with an I/O request (i.e. 
the sample fastfat driver, these routines are respectively 
FatFastQueryBasicInfo [1] and FatFastQueryNetworkOpenInfo [2].




Python tracker <>
Python-bugs-list mailing list

Reply via email to