-
-
Notifications
You must be signed in to change notification settings - Fork 30.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
ntpath.realpath() does not fully resolve relative paths #82634
Comments
Because the abspath() call is deferred until the end of the resolution process, if the current working directory is not already a real path, it will not be fully resolved. By passing it through abspath() at the start of the function, we ensure that the correct path is resolved. This will help resolve some inconsistencies in the test suite when tests are launched with a short filename (FILENA~1) in the working directory (though some other fixes are probably needed to help here). |
Updating change_cwd() in Lib/test/support/init.py to call chdir(realpath(path)) also fixes the test issues I was facing, but the realpath() implementation needs fixing. |
PR 16723 is just for the test fix. The realpath() fix should get tests that chdir (without change_cwd()) into a symlink and then realpath() on a relative path. Today, that should fail to resolve the sections in the CWD, and with the fix it should resolve the entire path. |
PR 16967 should fix the relative path resolution property, by joining with cwd if the original path is unprefixed and not absolute, and then joining with any symlink directories if their link is not absolute. |
I also had to special-case "realpath('nul')" to maintain the behaviour that we deliberately maintained in another bug, and I think isabs() should always return true for "\\?\" prefixed paths (given that join() will promote a "\\?\" prefixed path to the root). |
The discussion on the PR has raised one scenario where our algorithm conflicts with what we can reasonably emulate from the IO manager (which is itself not entirely self-consistent): If you call ntpath.realpath(r"C:\spam\eggs") where "spam" is a symlink/junction to "D:\foo\baz" and "D:\foo\baz\eggs" is a relative symlink to "..\bar" and "D:\foo\bar" does not exist, we will incorrectly return "C:\bar". Note that if "D:\foo\bar" *does* exist, we will return the correct result. And if "C:\spam" is *not* a symlink/junction, we will return the correct result. Essentially, we fail in the case where ntpath.exists(X) fails and realpath(dirname(X)) != dirname(X) and readlink(X).startswith("..\\") is True. Considering it's taken months of patient explanation from Eryk Sun for me to understand this, and nobody has ever complained about it, I'm prepared to call it a known limitation. |
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). |
I think the PR as it stands is a net improvement over where we currently are, so I'll merge it. We can make more tweaks as necessary. |
AMD64 Windows8.1 Non-Debug 3.x is grumpy: ====================================================================== Traceback (most recent call last):
File "D:\buildarea\3.x.ware-win81-release.nondebug\build\lib\test\test_ntpath.py", line 424, in test_realpath_cwd
self.assertPathEqual(test_file_long, ntpath.realpath(test_file_short))
File "D:\buildarea\3.x.ware-win81-release.nondebug\build\lib\test\test_ntpath.py", line 62, in assertPathEqual
self.assertEqual(path1, path2)
AssertionError: 'D:\\[88 chars]worker_4476\\@test_4476_tmp\\MyVeryLongDirectoryName\\file.txt' != 'D:\\[88 chars]worker_4476\\@test_4476_tmp\\MYVERY~1\\file.txt'
- D:\buildarea\3.x.ware-win81-release.nondebug\build\build\test_python_4088\test_python_worker_4476\@test_4476_tmp\MyVeryLongDirectoryName\file.txt
? ^ ^^^^^^^^^^^^^^^^^^^^
+ D:\buildarea\3.x.ware-win81-release.nondebug\build\build\test_python_4088\test_python_worker_4476\@test_4476_tmp\MYVERY~1\file.txt
? ^ ^^^^^ |
Grumpy AMD64 Windows10 3.x: ====================================================================== Traceback (most recent call last):
File "D:\buildarea\3.x.bolen-windows10\build\lib\test\test_ntpath.py", line 424, in test_realpath_cwd
self.assertPathEqual(test_file_long, ntpath.realpath(test_file_short))
File "D:\buildarea\3.x.bolen-windows10\build\lib\test\test_ntpath.py", line 62, in assertPathEqual
self.assertEqual(path1, path2)
AssertionError: 'D:\\[76 chars]worker_6956\\@test_6956_tmp\\MyVeryLongDirectoryName\\file.txt' != 'D:\\[76 chars]worker_6956\\@test_6956_tmp\\MYVERY~1\\file.txt'
- D:\buildarea\3.x.bolen-windows10\build\build\test_python_6236\test_python_worker_6956\@test_6956_tmp\MyVeryLongDirectoryName\file.txt
? ^ ^^^^^^^^^^^^^^^^^^^^
+ D:\buildarea\3.x.bolen-windows10\build\build\test_python_6236\test_python_worker_6956\@test_6956_tmp\MYVERY~1\file.txt
? ^ ^^^^^ pythoninfo: windows.RtlAreLongPathsEnabled: False |
Thanks, Victor! That looks different from the one I was originally fixing (even though the long/short path mismatch is there), so I'll take a look. |
Closing this as I believe it's done, but happy to reopen if we find another edge case (or start a new issue). |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: