zip 3.00: can't read some zip files

[vinc17@…]

zip 3.00 can't read some zip files:

$ zip -9ru ~/private/backup/oldarc.zip oldarc
        zip warning: expected 8468 entries but found 74004

zip error: Zip file structure invalid (/Users/vinc17/private/backup/oldarc.zip)
zsh: exit 3     zip -9ru ~/private/backup/oldarc.zip oldarc

This is a regression: no problem with zip 2.32. Until this bug is fixed, zip should be downgraded to 2.32.

[vinc17@…]

Note that 74004 - 8468 = 65536. I reported the problem upstream.

[(none)]

Milestone Port Bugs deleted

[ryandesign (Ryan Carsten Schmidt)]

Vincent had a longer discussion about this problem with the Debian folks here: ​https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=527388

What I was able to understand from that is that the zip 2 file specification supported a maximum of 65536 files in an archive. zip 2.32 had a method of working around that limit by storing an invalid count of items in the archive, which Vincent was relying on in the archive he created. The zip specification was later updated to support > 65536 files ("Zip64"), and zip 3 supports the new specification, but in the process appears to have lost the ability to deal natively with the pre-zip-3 invalid > 65536-file archives it created. It was suggested that Vincent should use the -FF flag to convert his old "invalid" zip 2 archive to a new valid zip 3 archive. He reported that this did not work, but that it was possible that using a newer version of unzip might allow it to work.

Since this bug only affects users who have archives created with zip 2 containing more than 65536 files, and since zip 3 has been out for 12 years, I don't think this problem is likely to affect many users. Since this is either a bug or an undocumented behavior in the upstream software (not a bug in MacPorts) I'm going to close it as wontfix. Of course if there is a patch to fix this bug we can apply it to MacPorts. I was not able to locate such a patch but there are 16 years worth of unresolved bug reports and patches in the zip sourceforge trackers so it's possible I missed something. Given the length of time since the last release of zip and the quantity of unregarded bug reports and patches, I would assume the upstream project is dead and we will not see a fix for this issue from the project's developers.

I would just add that since zip 2 was able to deal with these invalid archives, if anyone else has this problem, my suggestion (if the -FF suggestion doesn't work) would be to unpack the archive using zip 2 and then repack it using zip 3.