JDK-5084334 : Cannot handle zip files with more than 65535 files
The Version table provides details related to the release that this issue/RFE will be addressed.
Unresolved : Release in which this issue/RFE will be addressed. Resolved: Release in which this issue/RFE has been resolved. Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.
Zip a directory with more than 65535 files and then unzip it using java.util.zip. The unzip shows only x-65535 files where x is the number of files in the original directory.
There is an intrinsic 16-bit size limit to the number of entries in any
zip file. Nevertheless, we should not silently create an incomplete zip file,
but should throw an exception instead.
Perhaps in future, we can implement a non-standard extension to the zip file
format to allow more entries, or adopt a completely different archive format.
Zip files contain something like a "table of contents",
located at the end of the zip file. This table of contents
contains a count of the number of entries. ZipFile.entries() uses
this table of contents, while jar xf does not - it treats the zip
file like a kind of linear tape and ignores the table of contents.
It is impossible to store the actual number of entries in the table
of contents, since there are only 16 bits available. So Zip files
with more than 64k entries are simply corrupted -- the metadata
cannot be correct. jar cf should keep count of the number of entries,
and throw an exception if an attempt is made to add more than 64k.
Obviously I was wrong in my evaluation above, since I managed to fix it.
The key is to use the ENDTOT fields as merely a hint. See
4828461: Support Zip files with more than 64k entries
###@###.### 2005-2-14 09:09:59 GMT
BugTraq+ Release Management Values
COMMIT TO FIX: