This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author serhiy.storchaka
Recipients Kristof.Keppens, Paul, alanmcintyre, amaury.forgeotdarc, christian.heimes, craigds, dandrzejewski, enlavin, eric.araujo, gregory.p.smith, lambacck, loewis, nadeem.vawda, ronaldoussoren, segfault42, serhiy.storchaka
Date 2012-09-23.09:54:17
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1348394059.68.0.540424292243.issue9720@psf.upfronthosting.co.za>
In-reply-to
Content
I see two rational solutions of the issue (all written below is applicable only for allowZip64=True):

1) Always write Zip64 extended information extra field. This approach always successful, but the zipfile size will increase by 20 bytes for each file.

The first patch (zipfile_zip64_always.patch) uses this approach.

2) Write Zip64 extended information extra field only if assumed file size is more than a certain limit. In very rare cases this leads to the impossibility of compression of the file which can be compressed the first way. However it produces the same file as before patch in most cases.

The second patch (zipfile_zip64_try.patch) is based on Alan's patch and uses the second approach. The probability of errors is reduced and they are now detected and does not lead to a silent data damage.

Both patches are for Python 3.3. If any patch is good, I'll backport it for the older versions.
History
Date User Action Args
2012-09-23 09:54:20serhiy.storchakasetrecipients: + serhiy.storchaka, loewis, gregory.p.smith, ronaldoussoren, amaury.forgeotdarc, alanmcintyre, christian.heimes, nadeem.vawda, eric.araujo, lambacck, dandrzejewski, segfault42, craigds, enlavin, Paul, Kristof.Keppens
2012-09-23 09:54:19serhiy.storchakasetmessageid: <1348394059.68.0.540424292243.issue9720@psf.upfronthosting.co.za>
2012-09-23 09:54:19serhiy.storchakalinkissue9720 messages
2012-09-23 09:54:18serhiy.storchakacreate