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, paul.moore, sfmc, steve.dower, tim.golden, zach.ware
Date 2021-04-29.05:17:15
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
A substitute drive is not a mount point, strictly speaking. It's a symlink in the object namespace that targets an arbitrary path on a device, or even on another mapped/substitute drive. A mapped drive is a similar case that targets an arbitrary path on a UNC share. Any number of these path components may be filesystem symlinks, which can in turn target other substitute drives and mapped drives.

The object manager reparses your example substitute drive "Z:" to its target path r"C:\example\dir" before the I/O manager and filesystem ever see the path. Thus, hypothetically, if r"Z:\symlink" targets r"\spam", it resolves to r"C:\spam", not r"Z:\spam", i.e. not r"C:\example\dir\spam". If r"Z:\symlink" targets r"..\spam", it resolves to r"C:\example\spam". 

Also, substitute drives are almost always defined for the current logon session only. If you think it's not an issue because you're the only user on the machine, there's still typically a linked logon to worry about in the case of a UAC split standard/administrator logon; plus there are service processes running as SYSTEM, NETWORK SERVICE, and LOCAL SERVICE; and maybe also non-interactive tasks running as the user account in a separate logon session. Given that Windows is inherently a multiple-logon system, a path that's only accessible by one logon session in the system is not the best candidate for a real path if it's possible to resolve it further to a path that's globally accessible.


A mount point, unlike a symlink, is a graft point that behaves like a regular subtree. Classical mount points in Windows are the root paths of volume devices (e.g. "C:\\", where "C:" is a volume device name) and redirected filesystems mounted as UNC shares (e.g. r"\\server\share"). Windows 2000 added support for bind mount points (i.e. junctions, e.g. r"C:\Mount\F"). Unfortunately, switching to junctions probably won't solve your problem. The current design of ntpath.realpath() doesn't always retain a bind mount point in the resolved path, not unless it's the canonical path of a local volume -- or unless it's in a UNC path since it's impossible to resolve a remote junction to an accessible target path.
Date User Action Args
2021-04-29 05:17:17eryksunsetrecipients: + eryksun, paul.moore, tim.golden, zach.ware, steve.dower, sfmc
2021-04-29 05:17:17eryksunsetmessageid: <>
2021-04-29 05:17:17eryksunlinkissue43968 messages
2021-04-29 05:17:15eryksuncreate