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=18648>.
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=18648

<zip> still creates invalid file (NOT FIXED IN 1.5.3Beta1)

[EMAIL PROTECTED] changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                URL|                            |ftp://ftp.uu.net/pub/archivi
                   |                            |ng/zip/doc/
             Status|NEW                         |RESOLVED
         Resolution|                            |INVALID



------- Additional Comments From [EMAIL PROTECTED]  2003-04-03 10:01 -------
ZIP files created by Ant follow the spec defined in appnote-iz-latest that can
be found at the URL above.  In this, you'll find (under the description of
the general purpose bit in local file header):

          Bit 3: If this bit is set, the fields crc-32, compressed size
                 and uncompressed size are set to zero in the local
                 header.  The correct values are put in the data descriptor
                 immediately following the compressed data.  (Note: PKZIP
                 version 2.04g for DOS only recognizes this bit for method 8
                 compression, newer versions of PKZIP recognize this bit
                 for any compression method.)
                [Info-ZIP note: This bit was introduced by PKZIP 2.04 for
                 DOS. In general, this feature can only be reliably used
                 together with compression methods that allow intrinsic
                 detection of the "end-of-compressed-data" condition. From
                 the set of compression methods described in this Zip archive
                 specification, only "deflate" meets this requirement.
                 Especially, the method STORED does not work!
                 The Info-ZIP tools recognize this bit regardless of the
                 compression method; but, they rely on correctly set
                 "compressed size" information in the central directory entry.]

Ant does set bit 3 and sets both size values to 0 for compressed entries.
Ant does correctly set the size in both the data descriptor and the central
file header (at least for me).

It seems as if the tool you use is not able to properly recognize and/or
interpret this bit 3 - which it should better do as Ant also sets the version
required to extract the file to 2, which in turn requires the above to work.

Reply via email to