[issue15286] normpath does not work with local literal paths

Eryk Sun added the comment: This old issue still needs to be fixed. The check for special_prefixes in ntpath.normpath() must be removed in order to be consistent with WinAPI GetFullPathNameW(). In Windows, one can just call ntpath.abspath() to ensure that nt._getfullpathname() is called. But

[issue15286] normpath does not work with local literal paths

Change by Eryk Sun : -- Removed message: https://bugs.python.org/msg338058 ___ Python tracker ___ ___ Python-bugs-list mailing list

[issue15286] normpath does not work with local literal paths

Eryk Sun added the comment: For issue 7909, ntpath.normpath was modified to return the path unchanged if it begins with exactly either ".\\" or "?\\". Normalization is not skipped, however, if the prefix has one or more forward slashes instead of all backslashes. In this case, we can

[issue15286] normpath does not work with local literal paths

Change by Mark Lawrence : -- nosy: -BreamoreBoy ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail

[issue15286] normpath does not work with local literal paths

Mark Lawrence added the comment: As ntpath was cleaned up on #15275 do we need this patch or not, especially given that pathlib made it into 3.4? -- ___ Python tracker ___ _

[issue15286] normpath does not work with local literal paths

Mark Lawrence added the comment: As Antoine's pathlib made it into 3.4 is the patch here now obsolete or what? Also note the reference to issue15275. -- nosy: +BreamoreBoy ___ Python tracker _

[issue15286] normpath does not work with local literal paths

Antoine Pitrou added the comment: > May I ask you why you mention the symbolic links? I know that if one > of the segments of the path is a symbolic link there are problems but > this is not related to \\?\ or am I confused? Just curious :) No, it is not related with "\\?\" but I'm pointing out

[issue15286] normpath does not work with local literal paths

Manuel de la Pena added the comment: Antoine, What the MSDN is stating is that the Windows functions from COM will not normalize the path if it is prefixed by \\?\. That is, if a user wanted to do: path = r'\\?\C:\Users\mandel\..\Desktop\test' with open(path, 'w') as fd: fd.write('hello!'

[issue15286] normpath does not work with local literal paths

Antoine Pitrou added the comment: I think this is wrong. The MSDN doc says: “Because it turns off automatic expansion of the path string, the "\\?\" prefix also allows the use of ".." and "." in the path names, which can be useful if you are attempting to perform operations on a file with the

[issue15286] normpath does not work with local literal paths

Brian Curtin added the comment: Hi mandel :) With the exception of the "import string" inside of _get_letters (policy is to do all imports at the top), it looks ok just by reading. Assigning to myself to complete it after I return from holiday in a few days (unless someone beats me). --

[issue15286] normpath does not work with local literal paths

Changes by Antoine Pitrou : -- nosy: +brian.curtin, tim.golden stage: -> patch review ___ Python tracker ___ ___ Python-bugs-list mai

[issue15286] normpath does not work with local literal paths

New submission from Manuel de la Pena : Local literal paths are those paths that do use the \\?\ that allows to have paths longer that the MAX_PATH set by Windows (http://msdn.microsoft.com/en-us/library/windows/desktop/aa365247%28v=vs.85%29.aspx#short_vs._long_names). While UNC (http://en.wik