[issue38453] ntpath.realpath() does not fully resolve relative paths

Steve Dower report at bugs.python.org
Wed Nov 13 14:32:00 EST 2019


Steve Dower <steve.dower at python.org> added the comment:

My latest push to PR 16967 is a significant change to what ntpath.realpath will return for broken symlinks, but I think it's the right change.

Basically, if the OS fully resolves the path, great! We'll return that (and handle \\?\ stripping)

If the OS doesn't, we'll assume it's a broken link and try and read the link target from the path. Most of the time, we'll get "not a link", but if it succeeds then we'll return here. For absolute links, we'll return it. For relative symlinks, we'll join with the parent directory. For relative anything-else, we'll return the path to the link itself.

If we can't read a link (most likely), then we'll work up the path doing the same thing. Once we successfully get further than the original path, we'll join the unprocessed tail on and return without attempting to resolve anything more (assuming that the OS would have done it earlier if it was possible).

So if you look at the changed test_ntpath.py you'll see the different results (the test_shutil.py changes are mainly to avoid long/short name comparison failures when realpath() fixes them, by putting the test files in the actual test directory instead of global TEMP).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38453>
_______________________________________


More information about the Python-bugs-list mailing list