You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ant.apache.org by bu...@apache.org on 2002/11/15 14:28:03 UTC
DO NOT REPLY [Bug 13373] -
ZIP files: getSize() and getCompressedSize() return -1
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13373>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13373
ZIP files: getSize() and getCompressedSize() return -1
bodewig@apache.org changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |WONTFIX
------- Additional Comments From bodewig@apache.org 2002-11-15 13:28 -------
Ant's zip code is taking advantage of something that has been added to the
"version 2" of the ZIP format. Technically that is that you are allowed to
put -1 for the sizes into the "local file header" if you are deflating the
data. Ant does store the correct sized into the "central file header".
Recent Sun based JVM support this format (at least on Unix like systems) and even
create it themselves. Recent here is 1.1.8 on Linux for example.
Sorry, I don't think this is going to be fixed as fixing it requires Ant to
either compress the whole data to be stored in memory or to compress it twice
to determine the compressed size.
A workaround is to set compress to false. In this case Ant will store the
sizes in the local file header as well.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>