Steve Dower added the comment:
Right, what the prefix actually means is "treat this path as a blob and don't
do any processing". Some of the things that 'processing' includes are:
* CWD
* invalid names ('foo.' -> 'foo')
* adjacent backslashes ('a\\b' -> 'a\b')
* forward slashes ('a/b' -> 'a\b')
* (probably) short/long file names ('progra~1' -> 'Program Files')
A nice side-effect is that you can also use path names longer than 260
characters, provided your path name is correctly normalized already.
Really, the test for whether to keep or remove the prefix should be to remove
the prefix and try and resolve the path again. If it succeeds, remove the
prefix; otherwise, keep it. This can only really be done as part of the
resolve() call, which would address the original issue, but it may be quite a
perf. hit.
I'd still be inclined to add the prefix in str() if the final path length is
greater than 260 characters, if only because we go from zero chance of it
working to a non-zero chance. Unfortunately, there seems to be no way to
process a long path to make it 'safe' to add the prefix (though we can do a few
of the things and increase the chances) as GetFinalPathName will not work on a
long path. FWIW, paths longer than 260 chars are a mess and everyone knows it,
but it's really really hard to fix without breaking back-compat.
----------
_______________________________________
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue22299>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
