Author steve.dower
Recipients Kevin.Norris, eryksun, pitrou, steve.dower, tim.golden, zach.ware
Date 2014-09-08.15:49:13
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
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:

* 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.
Date User Action Args
2014-09-08 15:49:14steve.dowersetrecipients: + steve.dower, pitrou, tim.golden, zach.ware, eryksun, Kevin.Norris
2014-09-08 15:49:13steve.dowersetmessageid: <>
2014-09-08 15:49:13steve.dowerlinkissue22299 messages
2014-09-08 15:49:13steve.dowercreate