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 doesn't join paths correctly when a drive is present #63655
Comments
(Bruce Leban, on python-ideas:) """ >>> ntpath.join(r'\\a\b\c\d', r'\e\f')
'\\e\\f'
# should be r'\\a\b\e\f'
>>> ntpath.join(r'C:\a\b\c\d', r'\e\f')
'\\e\\f'
# should be r'C:\e\f' (same behavior in Python 2.7 and 3.3) (Let's also make sure PEP-428 / pathlib fixes this.) |
Looking at this some more, I think one of the reasons is that isabs() does not consider paths consisting of *just* a drive (either c: or \\host\share) to be absolute, but it considers a path without a drive but starting with a \ as absolute. So perhaps it's all internally inconsistent. I'm hoping Bruce has something to say to this. |
I'm willing to fix this. ntpath.join behaves weird in other situations too: >>> ntpath.join('C:/a/b', 'D:x/y')
'C:/a/b\\D:x/y' In fact, I don't know what the above should return. |
PEP-428 offers a reasonable view. Search http://www.python.org/dev/peps/pep-0428/ for "anchored" and read on. |
Added a possible fix for ntpath.join. Didn't touch isabs yet. |
A non-UNC windows path consists of two parts: a drive and a conventional path. If the drive is left out, it's relative to the current drive. If the path part does not have a leading \ then it's relative to the current path on that drive. Note that Windows has a different working dir for every drive. x\y.txt # in dir x in current dir on current drive UNC paths are similar except \\server\share is used instead of X: and there are no relative paths, since the part after share always starts with a \. Thus when joining paths, if the second path specifies a drive, then the result should include that drive, otherwise the drive from the first path should be used. The path parts should be combined with the standard logic. Some additional test cases tester("ntpath.join(r'C:/a/b/c/d', '/e/f')", 'C:\e\f') Andrei notes that the following is wrong but wonders what the correct answer is: >>> ntpath.join('C:/a/b', 'D:x/y')
'C:/a/b\\D:x/y' The /a/b part of the path is an absolute path on drive C and isn't "transferable" to another drive. So a reasonable result is simply 'D:x/y'. This matches Windows behavior. If on Windows you did $ cd /D C:\a\b
$ cat D:x\y it would ignore the current drive on C set by the first command and use the current drive on D. tester("ntpath.join('C:/a/b', 'D:x/y')", r'D:x/y') |
Do we even have a way to get the current directory for a given drive? (I guess this is only needed for C: style drives.) |
With previous patch: >>> ntpath.join('C:a/b', 'D:y/z')
'D:y/z\\y/z' Should be 'D:y/z'. Here is other patch which implements same algorithm as in pathlib (bpo-19908). Added new tests, removed duplicated tests. |
If there are no objections, I'll commit this patch tomorrow. |
I just discovered that perhaps ntpath.join should be even more clever. Windows supports current directories for every drive separately, so perhaps ntpath.join('c:/x', 'd:/y', 'c:z') should return 'c:/x\\z', not 'c:/z'. Could anyone please check it? Create directory x/z on drive c: and directory y on drive d:, then execute following commands: cd c:/x What is resulting current working directory? Here is a patch which implements this algorithm. |
'c:z' is consistent with what .NET's System.IO.Path.Combine does: via http://ironpython.net/try/ : returns 'c:z'
c:\>cd c:/x c:\x>cd e:\y c:\x>cd c:z c:\x>cd c:\z Yes, there is a seperate current directory for each drive, but cd does not switch drives. (cd e:\f does not mean you actually go to e:\f - it just changes the current directory on the e:-drive). I don't think those semantics are sensible for joining paths... |
Sorry, I was a bit too quick - I forgot to create c:\x\z. Now this is the result: c:\x\z>cd c:/x However, the behavior does not work in, for example, a 'Save as...' window, where c:z will always return "illegal filename" |
Thank you Merlijn for your information. So which patch is more preferable? |
I'm not sure whether that question was aimed at me -- I think both options have their merits, but I'd suggest to adopt the .NET semantics. The semantics are also explicitly defined [1] and the behavior seems to be acceptable for the .NET world. [1] http://msdn.microsoft.com/en-us/library/fyy7a5kt(v=vs.110).aspx |
I think a python programmer is going to expect that join(a, b, c) == join(join(a, b), c) so the answer to Serhiy's example should be 'c:z'. |
New changeset 6b314f5c9404 by Serhiy Storchaka in branch '2.7': New changeset f4377699fd47 by Serhiy Storchaka in branch '3.3': New changeset 7ce464ba615a by Serhiy Storchaka in branch 'default': |
Committed first patch (with small change, ntpath.join('c:', 'C:') now returns 'C:'). There is yet one argument for first option: it is almost impossible (with current design) to implement second option in pathlib. |
Hi Serhiy, there are commented-out lines in the 2.7 version of the patch. Are they intentionally there?: + #tester("ntpath.join('//computer/share', 'x/y')", '//computer/share\\x/y') + #tester("ntpath.join('//computer/share', '/x/y')", '//computer/share/x/y') |
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: