[issue9949] os.path.realpath on Windows does not follow symbolic links
Eryk Sun
report at bugs.python.org
Wed Aug 21 20:52:38 EDT 2019
Eryk Sun <eryksun at gmail.com> added the comment:
>> We can find code that does `relpath(realpath(target),
>> realpath(start))` to compute the relative path to target
>> for a symlink.
>> ...
> I don't know how common this scenario is, but I can certainly
> say that it's never worked on Windows. You'd also end up with a
> relative symlink in a _real_ directory somewhere (that the
> junction was pointing at) that is unable to reach `target`,
> because it's now being resolved against the wrong start.
With ntpath.realpath == ntpath.abspath, it actually works fine for just junctions because in most cases a mount point in Windows should be handled simply as just a directory, not resolved as its target. Revisit my example. This is what I showed when "C:/spam/scripts" is a junction. It's only wrong if the junction targets a directory symlink -- a chimeric mount-point-link that NT has made the mistake of allowing. (The kernel developers should have known to disallow this when they introduced Unix-like symlinks. When evaluating a mount point that targets a symlink, or any name-surrogate reparse point, it should fail the call as an invalid reparse point. For simplicity and our sanity, a mount point should always have consistent semantics in path parsing as a hard component that behaves like a regular directory. Then we could *always* handle it as just a directory -- whether it's local or remote. They messed up badly, IMO.)
----------
_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue9949>
_______________________________________
More information about the Python-bugs-list
mailing list