[issue3997] zipfile and winzip

Amaury Forgeot d'Arc added the comment: Yes, the correction went in r68678, r68700, r68734 and r68735 -- resolution: -> fixed status: open -> closed ___ Python tracker ___ _

[issue3997] zipfile and winzip

Brett Cannon added the comment: Amaury, did the buildbots verify this worked and thus this bug can be closed? -- nosy: +brett.cannon ___ Python tracker ___ __

[issue3997] zipfile and winzip

Changes by STINNER Victor : Removed file: http://bugs.python.org/file11850/zip-64k-2.patch ___ Python tracker ___ ___ Python-bugs-list mailing

[issue3997] zipfile and winzip

Changes by STINNER Victor : Removed file: http://bugs.python.org/file11841/zip-64k.patch ___ Python tracker ___ ___ Python-bugs-list mailing li

[issue3997] zipfile and winzip

Amaury Forgeot d'Arc added the comment: Applied the zip64-alwaystry2.patch in trunk, waiting for buildbots. ___ Python tracker ___ ___ Python-b

[issue3997] zipfile and winzip

Changes by Amaury Forgeot d'Arc : Removed file: http://bugs.python.org/file12778/zip64-alwaystry.patch ___ Python tracker ___ ___ Python-bugs-l

[issue3997] zipfile and winzip

Changes by Amaury Forgeot d'Arc : Added file: http://bugs.python.org/file12779/zip64-alwaystry2.patch ___ Python tracker ___ ___ Python-bugs-li

[issue3997] zipfile and winzip

Amaury Forgeot d'Arc added the comment: Oops, I did see this before, but forgot to merge the patches. It appears that "centDirOffset == 0x" is not the correct test for detecting zip64 structure. From the PKZip notes, a value of 0x does imply a zip64 format, not the other way r

[issue3997] zipfile and winzip

Antoine Pitrou added the comment: Reopening, some tests have started deterministically failing: == ERROR: testAbsoluteArcnames (test.test_zipfile.TestZip64InSmallFiles) --

[issue3997] zipfile and winzip

Amaury Forgeot d'Arc added the comment: Fixed with r68661 (trunk), r68662 (py3k), r68663 (2.6) and r68664 (3.0) -- resolution: accepted -> fixed status: open -> closed ___ Python tracker ___

[issue3997] zipfile and winzip

Martin v. Löwis added the comment: Looks fine to me. Please apply. -- keywords: -needs review ___ Python tracker ___ ___ Python-bugs-

[issue3997] zipfile and winzip

Amaury Forgeot d'Arc added the comment: Here is an updated version (zip-64k-3.patch). Now the condition for writing a "ZIP64 end-of-archive" depends on the size of all three values. Added file: http://bugs.python.org/file12775/zip-64k-3.patch ___ Python tra

[issue3997] zipfile and winzip

Martin v. Löwis added the comment: The patch looks nearly fine. AFAICT, care must be taken to always write a ZIP64 end-of-cd record whenever an end-of-cd field overflows; I think this patch is missing the condition centDirSize > ZIP64_LIMIT. -- assignee: -> amaury.forgeotdarc resolutio

[issue3997] zipfile and winzip

Changes by Martin v. Löwis : -- versions: +Python 2.7, Python 3.0, Python 3.1 ___ Python tracker ___ ___ Python-bugs-list mailing list

[issue3997] zipfile and winzip

Changes by Martin v. Löwis : -- priority: -> release blocker ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: ht

[issue3997] zipfile and winzip

vali <[EMAIL PROTECTED]> added the comment: I could verify that the patch works with both the Windows Compress utility, WinZip and 7zip. Thank you! ___ Python tracker <[EMAIL PROTECTED]> _

[issue3997] zipfile and winzip

Amaury Forgeot d'Arc <[EMAIL PROTECTED]> added the comment: OK, it seems that the "central directory size" and "central directory offset" must contain their actual value if it can fit in a 32bit int, even though the spec says "If an archive is in ZIP64 format and the value in this field is 0xF

[issue3997] zipfile and winzip

vali <[EMAIL PROTECTED]> added the comment: Thank you for the quick fix. I could verify that the issue is fixed in python 2.6 when I use WinZip to open an archive with more than 2^16 files created with attached script (bug.py). However the windows native compress utility does not seem to be able

[issue3997] zipfile and winzip

Amaury Forgeot d'Arc <[EMAIL PROTECTED]> added the comment: Right, this is a bug in zipfile.py. The official PKZIP specifications says: http://www.pkware.com/documents/casestudies/APPNOTE.TXT total number of entries in the central dir: (2 bytes) The total number of files in the

[issue3997] zipfile and winzip

vali <[EMAIL PROTECTED]> added the comment: The version I used should not have this limitation as archives created with other languages as Java or C# opens fine in WinZip 11.2 evaluation version. Also the same issue can be observed in Windows compress utility. ___

[issue3997] zipfile and winzip

Amaury Forgeot d'Arc <[EMAIL PROTECTED]> added the comment: An archive with more than 65535 files must use the "64-bit extensions" of the standard Zip format. Such archives cannot be opened by programs that do not understand these extensions. See http://www.winzip.com/wzdic.htm Which version of

[issue3997] zipfile and winzip

New submission from vali <[EMAIL PROTECTED]>: using ZipFile library with Python 2.6 or an earlier version creates archived files that are not compatible with windows compress or Winzip. Other programs like 7-Zip will not have a problem with the format. Bug Description: if it is attempted to cre