[issue15286] normpath does not work with local literal paths

[Eryk Sun]

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 "Lib/ntpath.py" is cross-platform.

--
assignee: brian.curtin -> 
components: +Library (Lib)
nosy: +paul.moore, steve.dower, zach.ware
stage: patch review -> needs patch
versions: +Python 3.10, Python 3.9 -Python 3.7

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue15286] normpath does not work with local literal paths

[Eryk Sun]

Change by Eryk Sun :


--
Removed message: https://bugs.python.org/msg338058

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue15286] normpath does not work with local literal paths

[Eryk Sun]

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 see that the old issue (e.g. \\.\nul -> 
\\nul) is no longer a problem. 

>>> os.path.normpath('//./nul')
'.\\nul'

Thus we can and should remove the check for `special_prefixes`.

Not normalizing local-device paths is inconsistent with WINAPI GetFullPathNameW 
(i.e. ntpath.abspath in Windows). Local-device paths are always normalized by 
the system when it's explicitly requested to do so. \\?\ local-device paths 
(with only backslash in the prefix) are only special cased to bypass 
normalization when creating or opening a file.

Also, it probably needs a separate issue, but ntpath.normpath should strip 
trailing spaces and dots from the final (or only) component for the sake of 
consistency with ntpath.abspath in Windows (where it calls GetFullPathNameW). 
For example:

>>> os.path.normpath(r'//?/C:\test . . .')
'?\\C:\\test . . .'
>>> os.path.abspath(r'//?/C:\test . . .')
'?\\C:\\test'

This normalization rule is common to all path types and all Windows versions. 
It should be supported for both ntpath.normpath and ntpath.abspath when called 
on a non-Windows platform. If an actual file or directory name ends with 
trailing dots and spaces, it is not a normal Windows path, and it should not be 
normalized.

--
nosy: +eryksun
versions: +Python 3.7, Python 3.8 -Python 3.3

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue15286] normpath does not work with local literal paths

[Mark Lawrence]

Change by Mark Lawrence :


--
nosy:  -BreamoreBoy

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue15286] normpath does not work with local literal paths

[Mark Lawrence]

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 rep...@bugs.python.org
http://bugs.python.org/issue15286
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue15286] normpath does not work with local literal paths

[Mark Lawrence]

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 rep...@bugs.python.org
http://bugs.python.org/issue15286
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue15286] normpath does not work with local literal paths

[Manuel de la Pena]

Manuel de la Pena man...@canonical.com 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!')

he will get the following:

[Errorno 22] Invalid argument. r'\\?\C:\Users\mandel\..\Desktop\test'

The same think would happen if a C function is used, that is, open is doing the 
right thing. On the other hand, the same code without the \\?\ works.

This makes it even more important to allow the normpath users to normalize such 
paths, that is, a developer knows that the path has more than 260 chars and 
wants to make sure that the path can be written in the system:

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 :)

Brian,

The ntpath module is a little mess (look at my other patch 
http://bugs.python.org/issue15275) and I think there are more performance 
problems hidden there somewhere...

I imported string within the function because the same is done in expandvars 
(around line 430) and wanted to follow the style that was already in use in the 
file. I do agree that imports at the top are the way to go :)

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15286
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue15286] normpath does not work with local literal paths

[Antoine Pitrou]

Antoine Pitrou pit...@free.fr 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 that normpath()
isn't very useful because of that. And Windows has symlink support
nowadays :-)

For the record, I'm trying to build a saner path-handling library at
http://pypi.python.org/pypi/pathlib/ . I hope to propose it for
inclusion in 3.4.

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15286
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue15286] normpath does not work with local literal paths

[Manuel de la Pena]

New submission from Manuel de la Pena man...@canonical.com:

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.wikipedia.org/wiki/Path_%28computing%29) paths should not 
be normalized, local paths that do use the \\?\ prefix should so that 
developers that use such a trink to allow longer paths on windows do not have 
to wrapp the call in the following way:

LONG_PATH_PREFIX = '\\?\'
path = path.replace(LONG_PATH_PREFIX, '')
result = LONG_PATH_PREFIX + os.path.normpath(path)

The possible solution would be for the normalization to work and return the 
path normalized with the prefix added.

--
components: Windows
files: literal-normpath.patch
hgrepos: 141
keywords: patch
messages: 164909
nosy: mandel
priority: normal
severity: normal
status: open
title: normpath does not work with local literal paths
versions: Python 3.3
Added file: http://bugs.python.org/file26307/literal-normpath.patch

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15286
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue15286] normpath does not work with local literal paths

[Antoine Pitrou]

Changes by Antoine Pitrou pit...@free.fr:


--
nosy: +brian.curtin, tim.golden
stage:  - patch review

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15286
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue15286] normpath does not work with local literal paths

[Brian Curtin]

Brian Curtin br...@python.org 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).

--
assignee:  - brian.curtin
keywords: +needs review
type:  - behavior

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15286
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue15286] normpath does not work with local literal paths

[Antoine Pitrou]

Antoine Pitrou pit...@free.fr 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 these otherwise 
reserved relative path specifiers as part of the fully qualified path.”

(from 
http://msdn.microsoft.com/en-us/library/aa365247%28v=vs.85%29.aspx#namespaces)

So by normalizing the extended path, you are actually changing its meaning.

Furthermore, normpath() is generally wrong in the face of symlinks, meaning it 
shouldn't be used at all.

--
nosy: +pitrou

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15286
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com