Archive Utility on macOS Monterey fails to uncompress some zip files that previous macOS versions handled well

Originator:tempelmann
Number:rdar://FB9986408 Date Originated:18 Apr 2022
Status:Open Resolved:
Product:macOS Product Version:12.3.1
Classification:Incorrect behavior Reproducible:always
 
I've attached a .zip file (gzipped version: http://files.tempel.org/Various/zip64sample.zip.gz) that fails to uncompress correctly when opened by Archive Utility (e.g. double click in Finder).

It should create a file of about 4 GB in size (4'294'967'301 bytes, which is 2^32+5), but it creates one of only 5 bytes.

When uncompressing the same file on older macOS versions (I've tried High Sierra) or with command line tools such as "unzip", the result is correct.

This is a fairly serious regression because it leads to zip files not uncompressing that uncompressed well before.

And it shouldn't matter that the zip file contains a file whose size is >32 bit, because all other common zip tools before and current can correctly uncompress it regardless. The bug is that the new Archive Utility ignores that possibility and shortens the extracted file (which initially indeed extracts to the full 4GB in length, it appears) to the 32bit value it finds in the directory (which is 5).

Sure, the zip64 format is _supposed_ to be used for such cases, but there are many zip files out there that aren't using that format, and they should still extract just fine, which is possible. In fact, it was, until this regression.

Fact is that this zip file was created on macOS High Sierra, using Finder's "Compress" command, so it's Apple's own tool that created this file, and since it also used to uncompress correctly, you can't blame anyone but Apple on this :)

So please fix this issue in Archive Utility (or in ditto or whatever it uses beneath) instead of demanding that everyone "does it right", and thereby failing to uncompress backups people may have made with Apple's own tools in the past. Please don't punish all us by ignoring that old mistake by deciding to not working around it any more.

--P.S.--

Actually, it appears that the decompression utility does not even first create the full 4GB file before shortening it afterwards. Instead, it appears to stop uncompressing once it believes it has reached the "uncompressed size", even though the compressed zip stream keeps feeding data and hasn't reached its end, yet. The proper decompression behavior would be to continue to uncompress the stream until it returns that it's at its end, like unzip and other tools (and older Archive Utility) do it.

Comments


Please note: Reports posted here will not necessarily be seen by Apple. All problems should be submitted at bugreport.apple.com before they are posted here. Please only post information for Radars that you have filed yourself, and please do not include Apple confidential information in your posts. Thank you!