Eryk Sun <eryk...@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 <rep...@bugs.python.org> <https://bugs.python.org/issue9949> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
