[issue29805] Pathlib.replace cannot move file to a different drive on Windows if filename different
Laurent Mazuel added the comment: Just to confirm, I was able to workaround it with Py3.6: # client_generated_path.replace(destination_folder) shutil.move(client_generated_path, destination_folder) It is reasonable to think about adding a similar feature to pathlib if it doesn't support it and just special-case the drive-to-drive scenario for Windows -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue29805> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29805] Pathlib.replace cannot move file to a different drive on Windows if filename different
New submission from Laurent Mazuel: Trying to use Pathlib and Path.replace on Windows if drive are different leads to an issue: File "D:\myscript.py", line 184, in update client_generated_path.replace(destination_folder) File "c:\program files (x86)\python35-32\Lib\pathlib.py", line 1273, in replace self._accessor.replace(self, target) File "c:\program files (x86)\python35-32\Lib\pathlib.py", line 377, in wrapped return strfunc(str(pathobjA), str(pathobjB), *args) OSError: [WinError 17] The system cannot move the file to a different disk drive: 'C:\\MyFolder' -> 'D:\\MyFolderNewName' This is a known situation of os.rename, and workaround I found is to use shutil or to copy/delete manually in two steps (e.g. http://stackoverflow.com/questions/21116510/python-oserror-winerror-17-the-system-cannot-move-the-file-to-a-different-d) When using Pathlib, it's not that easy to workaround using shutil (even if thanks to Brett Cannon now shutil accepts Path in Py3.6, not everybody has Py3.6). At least this should be documented with a recommendation for that situation. I love Pathlib and it's too bad my code becomes complicated when it was so simple :( -- components: IO, Windows messages: 289549 nosy: Laurent.Mazuel, paul.moore, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: Pathlib.replace cannot move file to a different drive on Windows if filename different versions: Python 3.5, Python 3.6 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue29805> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26660] tempfile.TemporaryDirectory() cleanup exception on Windows if readonly files created
New submission from Laurent Mazuel: Using tempfile.TemporaryDirectory() in Windows, creating read-only files in this temp directory leads to PermissionError during the cleanup(). This is a direct cause of this one: https://bugs.python.org/issue19643 And the workaround which was proposed in the issue 19643 and added to the doc here: https://docs.python.org/3/library/shutil.html?highlight=shutil#rmtree-example is not used in the TemporaryDirectory implementation. I don't know if the right solution is to modify the implementation to systematically delete read-only files using the cited workaround, or to add a 'remove_readonly' flag or to update the documentation to clearly says that cleanup will raise a PermissionError if the user creates a read-only file. At least documentation please :) In my specific usecase I "git clone" in the temp directory, and the .git folder contains read-only files. Full stacktrace: Traceback (most recent call last): File "C:\mycode.py", line 149, in build_libraries update(generated_path, dest_folder) File "C:\Program Files\Python35\lib\tempfile.py", line 807, in __exit__ self.cleanup() File "C:\Program Files\Python35\lib\tempfile.py", line 811, in cleanup _shutil.rmtree(self.name) File "C:\Program Files\Python35\lib\shutil.py", line 488, in rmtree return _rmtree_unsafe(path, onerror) File "C:\Program Files\Python35\lib\shutil.py", line 378, in _rmtree_unsafe _rmtree_unsafe(fullname, onerror) File "C:\Program Files\Python35\lib\shutil.py", line 378, in _rmtree_unsafe _rmtree_unsafe(fullname, onerror) File "C:\Program Files\Python35\lib\shutil.py", line 378, in _rmtree_unsafe _rmtree_unsafe(fullname, onerror) File "C:\Program Files\Python35\lib\shutil.py", line 378, in _rmtree_unsafe _rmtree_unsafe(fullname, onerror) File "C:\Program Files\Python35\lib\shutil.py", line 383, in _rmtree_unsafe onerror(os.unlink, fullname, sys.exc_info()) File "C:\Program Files\Python35\lib\shutil.py", line 381, in _rmtree_unsafe os.unlink(fullname) PermissionError: [WinError 5] Access is denied: 'C:\\Users\\me\\AppData\\Local\\Temp\\tmpk62cp34t\\readonly.file' -- components: Library (Lib) messages: 262584 nosy: Laurent.Mazuel priority: normal severity: normal status: open title: tempfile.TemporaryDirectory() cleanup exception on Windows if readonly files created type: enhancement versions: Python 3.5 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue26660> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20329] zipfile.extractall fails in Posix shell with utf-8 filename
Laurent Mazuel added the comment: Thank for your answer. Unfortunately, I cannot test easily python 3.4 for now. But I have downloaded the source code and diff from 3.3 to 3.4 the zipfile module and see no difference relating to this problem. I can be wrong, maybe if some core improvement of Python may change something? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20329 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20797] zipfile.extractall should accept bytes path as parameter
New submission from Laurent Mazuel: Many methods which use path in Python now accept string or bytes in parameter (e.g. all methods in os.path, the open method, etc.). Actually, sometimes it is not possible to handle a file without using bytes path. For example, path coded in another encoding system than the current locale system (e.g. a Windows filename encoded in cp1252 against a Linux utf-8 system). Since zipfile.extractall uses path, it should accept bytes as path. Currently it leads to an error: File /usr/local/lib/python3.3/zipfile.py, line 1262, in _extract_member targetpath = os.path.join(targetpath, arcname) File /usr/local/lib/python3.3/posixpath.py, line 92, in join components.) from None TypeError: Can't mix strings and bytes in path components. This bug is closely related to bug 20329 but is not the same (but maybe this enhancement will create a good debate around bytes support in zipfile module :-) ) -- components: Library (Lib) messages: 212358 nosy: Laurent.Mazuel priority: normal severity: normal status: open title: zipfile.extractall should accept bytes path as parameter type: enhancement versions: Python 3.3 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20797 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10614] ZipFile: add a filename_encoding argument
Changes by Laurent Mazuel laurent.maz...@gmail.com: -- nosy: +Laurent.Mazuel ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10614 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20329] zipfile.extractall fails in Posix shell with utf-8 filename
New submission from Laurent Mazuel: Hello, Considering a zip file which contains utf-8 filenames (as uploaded zip file), the following code fails if launched in a Posix shell. with zipfile.ZipFile(test_ut8.zip) as fd: ... fd.extractall() ... Traceback (most recent call last): File stdin, line 2, in module File /opt/python/3.3/lib/python3.3/zipfile.py, line 1225, in extractall self.extract(zipinfo, path, pwd) File /opt/python/3.3/lib/python3.3/zipfile.py, line 1213, in extract return self._extract_member(member, path, pwd) File /opt/python/3.3/lib/python3.3/zipfile.py, line 1276, in _extract_member open(targetpath, wb) as target: UnicodeEncodeError: 'ascii' codec can't encode characters in position 10-14: ordinal not in range(128) With shell: $ locale LANG=POSIX ... But filesystem is not encoding dependant. On a Unix system, filename are only bytes, there is no reason to refuse to unzip a zip file (in fact, unzip command line don't fail to unzip the file in a Posix shell). Since open can take bytes filename, changing the line 1276 from open(targetpath) to: open(targetpath.encode(utf-8)) fixes the problem. zipfile should not care about the encoding of the filename and should use the bytes sequence filename extracted directly from the bytes sequence of the zipfile. Having ZipInfo.filename as a string (and not bytes) is great for an API, but is not needed to open/write a file on the disk. Then, ZipInfo should store the direct bytes sequences of filename as a bytes_filename field and use it in the open of extract. In addition, considering the patch of bug 10614, the right patch could use the new ZipInfo.encoding field: open(targetpath.encode(member.encoding)) -- components: Extension Modules files: test_ut8.zip messages: 208648 nosy: Laurent.Mazuel priority: normal severity: normal status: open title: zipfile.extractall fails in Posix shell with utf-8 filename type: behavior versions: Python 3.3 Added file: http://bugs.python.org/file33589/test_ut8.zip ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20329 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20329] zipfile.extractall fails in Posix shell with utf-8 filename
Laurent Mazuel added the comment: Thanks for your answer. I think you can't transcode internal zip filenames to FS encoding. Actually, in Unix the FS only stores bytes for filename, there is no FS encoding. Then, if you change your locale, the filename printed will change too in your console. If you transcode filename using the current locale, unzipping twice the same file with two different locales will lead to two different files, which is not (I think) you are intending for. The problem will not arise in Windows (NTFS is UTF-16) nor MAC OSX (UTF-8) Moreover, a simple unzip works like a charm. It doesn't care about encoding or current locale and extract the file using the initial bytes in the zip. Unzipping twice with the two different locales creates only one file. An interesting link (even if it is not an official reference): http://unix.stackexchange.com/questions/2089/what-charset-encoding-is-used-for-filenames-and-paths-on-linux -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20329 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11085] expose _abcoll as collections.abc
Changes by Laurent Mazuel laurent.maz...@gmail.com: -- nosy: +Laurent.Mazuel ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11085 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13498] os.makedirs exist_ok documentation is incorrect, as is some of the behavior
Changes by Laurent Mazuel laurent.maz...@gmail.com: -- nosy: +Laurent.Mazuel ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13498 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1596321] KeyError at exit after 'import threading' in other thread
Laurent Mazuel laurent.maz...@gmail.com added the comment: Another solution for cx-freeze problem: http://code.google.com/p/modwsgi/issues/detail?id=197#c5 Which can be added in ConsoleKeepPath.c for instance -- nosy: +Laurent.Mazuel ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1596321 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
