Opened 15 years ago

Closed 4 years ago

#17860 closed defect (wontfix)

zip 3.00: can't read some zip files

Reported by: vinc17@… Owned by: macports-tickets@…
Priority: Normal Milestone:
Component: ports Version: 1.7.0
Keywords: Cc:
Port: zip

Description

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.

Change History (3)

comment:1 Changed 15 years ago by vinc17@…

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

comment:2 Changed 15 years ago by (none)

Milestone: Port Bugs

Milestone Port Bugs deleted

comment:3 Changed 4 years ago by ryandesign (Ryan Carsten Schmidt)

Keywords: regression removed
Resolution: wontfix
Status: newclosed

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.

Note: See TracTickets for help on using tickets.