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 eryksun, nijave, paul.moore, steve.dower, tim.golden, zach.ware
Date 2022-02-16.12:48:19
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1645015699.57.0.426740918945.issue46763@roundup.psfhosted.org>
In-reply-to
Content
Python uses the volume serial number (VSN) and file ID for st_dev and st_ino. The OS allows the file ID to be 0 if the filesystem doesn't support file IDs. Also, it does not require or force the VSN to be a unique ID in the system, though if it's not 0 it's almost always a random 32-bit number for which the chance of collision is vanishingly small (notwithstanding a volume shadow copy, apparently). This means that (st_dev, st_ino) by itself is not sufficient to check whether two paths are the same file in Windows.

Proposal:

When comparing two file paths, if their (st_dev, st_ino) values differ, then they're not the same file. If their (st_dev, st_ino) values are the same, use the final NT paths from calling GetFinalPathNameByHandleW() with the flags VOLUME_NAME_NT | FILE_NAME_NORMALIZED. If only one of the paths supports FILE_NAME_NORMALIZED, then they're not the same file. If neither supports FILE_NAME_NORMALIZED, fall back on VOLUME_NAME_NT | FILE_NAME_OPENED. If either st_dev is 0 or st_ino is 0, the files are the same only if the final NT paths are the same. Else split out each device path. If the device paths are the same, then the paths are the same file. Otherwise they're different files.

We should probably special case the comparison of a multiple UNC provider path with a local volume path. For example r'\\localhost\C$\Windows' is the same as r'C:\Windows'. The corresponding NT paths are r'\Device\Mup\localhost\C$\Windows' and typically r'\Device\HarddiskVolume2\Windows'. The special case is that when one of the device paths is "\Device\Mup", the two device paths are not required to be the same. Of course, this is given that the (st_dev, st_ino) values are the same, and neither st_dev nor st_ino is zero.

That said, we would need to exclude volume shadow copies from the special case. I suppose we could just look for "VolumeShadowCopy" in the device name. Maybe we can do better. I've noticed that querying IOCTL_STORAGE_GET_DEVICE_NUMBER fails for a volume shadow copy, but that's probably going overboard.
History
Date User Action Args
2022-02-16 12:48:19eryksunsetrecipients: + eryksun, paul.moore, tim.golden, zach.ware, steve.dower, nijave
2022-02-16 12:48:19eryksunsetmessageid: <1645015699.57.0.426740918945.issue46763@roundup.psfhosted.org>
2022-02-16 12:48:19eryksunlinkissue46763 messages
2022-02-16 12:48:19eryksuncreate