EVALUATION

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.

###@###.### 2004-08-09

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.

###@###.### 2004-08-09

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
                                     

CONVERTED DATA

BugTraq+ Release Management Values

COMMIT TO FIX:
mustang