You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I actually haven't tested your code to see if it already supports this, but since I just wrote something about Apple's special zip format (https://iosdev.space/@tempelorg/111993220533529890), I thought I'd look for hastags on zip64 and found this.
So here's the deal: In order to allow >4GB files compressed without using zip64, Apple simply streams the entire file while leaving the sizes in the header set to zero. And the entry in the directory contains the size mod 2^32, of course. So you cannot predict the resulting size, but Apple's unzip can still decompress the files because it blindly decompresses the stream until its end marker.
Would you nice if you support that, too, and spread the word, as Apple has sadly not made this very public.
I'm happy to provide more info and sample files.
The text was updated successfully, but these errors were encountered:
I actually haven't tested your code to see if it already supports this
I haven't either! The last development push for 4.0 was sponsored by a company using that crate: I have no personal plans to support that variant or even test if it's already supported, but if someone else wants to, I'll do my best to guide them and get their contributions merged.
I actually haven't tested your code to see if it already supports this, but since I just wrote something about Apple's special zip format (https://iosdev.space/@tempelorg/111993220533529890), I thought I'd look for hastags on zip64 and found this.
So here's the deal: In order to allow >4GB files compressed without using zip64, Apple simply streams the entire file while leaving the sizes in the header set to zero. And the entry in the directory contains the size mod 2^32, of course. So you cannot predict the resulting size, but Apple's unzip can still decompress the files because it blindly decompresses the stream until its end marker.
Would you nice if you support that, too, and spread the word, as Apple has sadly not made this very public.
I'm happy to provide more info and sample files.
The text was updated successfully, but these errors were encountered: