- [PATCH 2/3] Have _zip_add_entry work on zip_array_t instead of zip_t., (continued)
- [PATCH 2/3] Have _zip_add_entry work on zip_array_, Jay Freeman (saurik) (2016/08/16 09:10:55)
- [PATCH 3/3] Support zip files with >0xffff entries, Jay Freeman (saurik) (2016/08/16 09:11:35)
- [PATCH 1/3] Use zip_array_t to unify zip_t and zip, Jay Freeman (saurik) (2016/08/16 09:11:35)
Re: [PATCH 0/3] libzip does not use EOCD nentry fi,
- Re: [PATCH 0/3] libzip does not use EOCD nentry fi, Thomas Klausner (2016/08/25 12:09:55)
I'm not looking at any of the libzip code, but I agree with Jay's strategy.
On Tue, Aug 16, 2016 at 1:54 AM, Jay Freeman (saurik) <saurik%saurik.com@localhost> wrote:
As described in my previous e-mail, I'm trying to work with zip files that
are generated by Apple for use with their OTA update mechanism, which have
more than 65k files but are stored using the 16-bit file format. These are
fully supported by PK-WARE's unzip utility, *on purpose, not on accident*.
I worked on the JDK's zip implementation - here's a comment I wrote many years ago:
/* Initialize zip file data structures based on the total number
* of central directory entries as stored in ENDTOT. Since this
* is a 2-byte field, but we (and other zip implementations)
* support approx. 2**31 entries, we do not trust ENDTOT, but
* treat it only as a strong hint.
There's also the other common bug of seeing that ENDTOT is 0xFFFF and assuming that means ZIP64 is surely being used.
Made by MHonArc.