Message313044
FWIW, yes, this is because zipimport doesn't support ZIP64, and doesn't even flag it as an error when the ZIP requires it. Instead it skips files; the ZIP64 format works by setting the fields that would overflow to the maximum value as a signal that the real value should be read from the ZIP64 records, which means it's still a valid non-64-bit ZIP file, just a truncated one.
Adding ZIP64 support to zipimport is not trivial, and requires breaking some behaviour that's bad (not according to the ZIP spec) but actually covered by zipimport's tests: prepending arbitrary data to the ZIP file by just concatenating them together (rather than rewriting the ZIP archive's offsets). I don't think there's going to be an easy fix here, although I am working on open-sourcing a replacement zipimport that I wrote for work, which does support ZIP64 properly (and also fixes some other fundamental flaws in zipimport). I hope to have that done soon, and we can discuss replacing zipimport with that module in Python 3.8 or later. |
|
Date |
User |
Action |
Args |
2018-02-28 01:30:35 | twouters | set | recipients:
+ twouters, mchouza, bbayles |
2018-02-28 01:30:34 | twouters | set | messageid: <1519781434.9.0.467229070634.issue32959@psf.upfronthosting.co.za> |
2018-02-28 01:30:34 | twouters | link | issue32959 messages |
2018-02-28 01:30:33 | twouters | create | |
|