Michal Charemza

> In that case, I think what I might do is start a new branch that fixes the lowercase issue only, create a PR for that Have now done this...

Same with me http://github.com/michalc/Fx.Presets/ I started added this, ahem, several months ago, had incorrect structure, no tags etc, but have only just gotten around to fixing them. Or at least,...

> This generally follows the strategy outlined by Mark Adler for his sunzip streaming unzip implementation, except that here I accept the shortest end-of-data marker that matches, rather than the...

Hi @kientzle, Ah thanks for the reply. Hexdumps follow #### First 256 bytes ``` $ hexdump -C -n 256 file.zip 00000000 50 4b 03 04 14 00 08 08 08...

I've just discovered something, I made the member files a bit bigger still, and the error occurs again, e.g. I can get: ``` cpio: ZIP uncompressed data is wrong size...

> I can think of some heuristics we might use -- try both layouts and accept whichever one seems to work, look for a "PK" signature following the data descriptor...

> There may be ways to make that more robust, but I'll have to think about the various failure cases. Yeah I wasn't really sure. I would love to have...

Ah just remembered - one reason why I didn’t default to writing Zip64 was that I think LibreOffice doesn’t support documents that are zipped using Zip64 https://bugs.documentfoundation.org/show_bug.cgi?id=128244

Ah _longest_ one that matches! So far I've been choosing the shortest out of, well, just doing the simplest thing. I er, might steal that for https://github.com/uktrade/stream-unzip (if no objection)

> For what it's worth: Libarchive's streaming writer handles this by always using Zip64 mode when writing entries whose size is not known in advance. That includes tagging the right...