This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author eryksun
Recipients Deniz Bozyigit, eryksun, gary ruben, giampaolo.rodola, paul.moore, r.david.murray, steve.dower, tim.golden, zach.ware
Date 2019-02-20.01:45:32
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
> I don't see any value in testing the drive name separately. 

If the file number is non-zero, then the volume is the only question. I limited the comparison to just the drives in case the volume supports hardlinks. We can change the check to `s1.st_ino and s1.st_nlink > 1`, so we only incur the expense when necessary. Maybe that's never in practice, but I'd rather error on the side of caution.

Anyway, it turns out we can't use splitdrive(). It doesn't handle UNC device paths the same way as regular UNC paths. It returns "\\?\UNC" as the drive for "\\?\UNC\server\share", whereas for a regular UNC path the drive is "\\server\share". 

> Would it make sense to add a parameter to _getfinalpathname that 
> specifies the type of the path? For same[open]file(), we can 
> probably just go to the most unreadable but broadly supported 
> type

That's probably the simplest change we can make here, in addition to file-descriptor support. The non-normalized NT path (VOLUME_NAME_NT | FILE_NAME_OPENED) is the most broadly supported and cheapest path to get. It's just two system calls: NtQueryObject and NtQueryInformationFile.
Date User Action Args
2019-02-20 01:45:32eryksunsetrecipients: + eryksun, paul.moore, giampaolo.rodola, tim.golden, r.david.murray, zach.ware, steve.dower, Deniz Bozyigit, gary ruben
2019-02-20 01:45:32eryksunsetmessageid: <>
2019-02-20 01:45:32eryksunlinkissue33935 messages
2019-02-20 01:45:32eryksuncreate