[2.7] bpo-32539: Fix OSError for os.listdir for extended paths on Windows#5169
Conversation
46dff86 to
2913561
Compare
There was a problem hiding this comment.
Quote \\?\ with double backticks.
Lib/test/test_os.py
Outdated
There was a problem hiding this comment.
Do WinCE or OS/2 support such path syntax?
There was a problem hiding this comment.
I don't actually have access to either of those environments -- is there an easy way I can check?
Lib/test/test_os.py
Outdated
There was a problem hiding this comment.
Does this directory exist? What if run python -m test -m test_listdir_extended_length_path test_os?
There was a problem hiding this comment.
it would crash otherwise, it's set up as part of this code:
Lines 71 to 73 in ab95b30
Lib/test/test_os.py
Outdated
There was a problem hiding this comment.
Does it matter if the directory empty? What if other files are left after other tests? Is it worth to test non-empty directory?
There was a problem hiding this comment.
I believe the setUp / tearDown ensure this is empty, the contents of the directory don't actually matter, just that it exists and that the listdir(...) call does not crash. I added the assertion so it looks less like a useless test :)
2913561 to
12c92ef
Compare
|
Did some research! os/2 does not support this: I spent hours trying to get a working windows CE emulator with some amount of command prompt and failed -- I've got no idea how the file system works there |
|
In Python 3 there is a special test for this: Win32ListdirTests.test_listdir_extended_path. Do you mind to backport it to 2.7? Interesting that Unicode paths are handled correctly. |
390c20f to
354beaf
Compare
See https://msdn.microsoft.com/en-us/library/windows/desktop/aa365247(v=vs.85).aspx?f=255&MSPPError=-2147217396#maxpath Paths that begin with `\\?\` are "extended-length paths".
354beaf to
0555344
Compare
|
Backported the tests! Had to make these patches for compatibility: --- py3 2018-01-15 09:58:09.123788000 -0800
+++ py2 2018-01-15 09:57:15.973225999 -0800
@@ -21,27 +21,29 @@
def test_listdir_no_extended_path(self):
"""Test when the path is not an "extended" path."""
# unicode
+ fs_encoding = sys.getfilesystemencoding()
self.assertEqual(
- sorted(os.listdir(support.TESTFN)),
- self.created_paths)
+ sorted(os.listdir(support.TESTFN.decode(fs_encoding))),
+ [path.decode(fs_encoding) for path in self.created_paths])
# bytes
self.assertEqual(
sorted(os.listdir(os.fsencode(support.TESTFN))),
- [os.fsencode(path) for path in self.created_paths])
+ self.created_paths)
def test_listdir_extended_path(self):
"""Test when the path starts with '\\\\?\\'."""
# See: http://msdn.microsoft.com/en-us/library/windows/desktop/aa365247(v=vs.85).aspx#maxpath
# unicode
- path = '\\\\?\\' + os.path.abspath(support.TESTFN)
+ fs_encoding = sys.getfilesystemencoding()
+ path = u'\\\\?\\' + os.path.abspath(support.TESTFN.decode(fs_encoding))
self.assertEqual(
sorted(os.listdir(path)),
- self.created_paths)
+ [path.decode(fs_encoding) for path in self.created_paths])
# bytes
- path = b'\\\\?\\' + os.fsencode(os.path.abspath(support.TESTFN))
+ path = b'\\\\?\\' + os.path.abspath(support.TESTFN)
self.assertEqual(
sorted(os.listdir(path)),
- [os.fsencode(path) for path in self.created_paths])
+ self.created_paths) |
OSError for os.listdir for deep paths on windowsOSError for os.listdir for extended paths on Windows
|
"Interesting that Unicode paths are handled correctly." That would have gone unfixed for all of a day at most. It's extremely rare to use a non-Unicode extended path. It can help to get around some quirks of the DOS namespace, such as DOS devices and files ending with dots and trailing spaces, but such names should be avoided in general anyway. The primary reason most people use extended paths is to avoid the (emulated DOS) |
See https://msdn.microsoft.com/en-us/library/windows/desktop/aa365247(v=vs.85).aspx?f=255&MSPPError=-2147217396#maxpath
Paths that begin with
\\?\are "extended-length paths".https://bugs.python.org/issue32539