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=19195>. 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=19195 Checksum values are -1 for the files in the zip created through ant [EMAIL PROTECTED] changed: What |Removed |Added ---------------------------------------------------------------------------- Severity|Major |Normal ------- Additional Comments From [EMAIL PROTECTED] 2003-07-15 13:56 ------- What you see is the same behavior that java.util.zip.ZipOutputStream generates. java.util.zip.ZipInputStream is conceptually broken, you shouldn't use it. If you encounter an archive with holes in it (i.e. areas that are not assigned to any zip entry according to the central directory) it is going to fail badly. Better to use ZipFile instead of ZipInputStream. You are correct, the situation could be improved, but the improvement comes with a cost - we'd have to either compress the data twice or store the compressed data in memory, which will become a big problem when we are including big files. The command line unzip tool has no problems with the current format, and a workaround - even if ugly - exists. Another option is to not compress the archive. I'm lowering the severity of this report because of this. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
