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-30.20:13:30
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1619813610.47.0.531690305539.issue43968@roundup.psfhosted.org>
In-reply-to
Content
> In our organization we use substituted drives for development, and 
> no other tools (including other programming languages and their IDEs),
> except for Python 3.8+, had any problems with this.

How about keeping a substitute or mapped drive from the input path if resolving the root path on the drive prefixes the overall real path? That would be pretty easy to implement.

Still, descendant relative symlinks will traverse through the supposed root to the actual real path. Given "Z:" is a substitute drive for r"C:\example\dir", if r"Z:\symlink" targets r"\spam", it will resolve to r"C:\spam", and if it targets  r"..\spam", it will resolve to r"C:\example\spam". That violates the assumption that a relative symlink can be resolved against a real path via readlink(), join(), and normpath().

The nearest equivalent to Linux bind mounts are mount-point reparse points (junctions). But the final-path design of realpath() doesn't work how I'd want in that regard. Given the limitations with junctions, if I had to do something like what you're doing, presuming UNC paths are allowed, I'd use a local-only share created via `net share sharename=path /grant:local,full`, accessed as "//localhost/sharename". A share is a bind mount in the namespace of the "UNC" DOS device.
History
Date User Action Args
2021-04-30 20:13:30eryksunsetrecipients: + eryksun, paul.moore, tim.golden, zach.ware, steve.dower, sfmc
2021-04-30 20:13:30eryksunsetmessageid: <1619813610.47.0.531690305539.issue43968@roundup.psfhosted.org>
2021-04-30 20:13:30eryksunlinkissue43968 messages
2021-04-30 20:13:30eryksuncreate