Return-Path: Delivered-To: apmail-jakarta-ant-user-archive@apache.org Received: (qmail 1494 invoked from network); 3 Apr 2002 14:38:24 -0000 Received: from unknown (HELO nagoya.betaversion.org) (192.18.49.131) by daedalus.apache.org with SMTP; 3 Apr 2002 14:38:24 -0000 Received: (qmail 4956 invoked by uid 97); 3 Apr 2002 14:38:10 -0000 Delivered-To: qmlist-jakarta-archive-ant-user@jakarta.apache.org Received: (qmail 4940 invoked by uid 97); 3 Apr 2002 14:38:09 -0000 Mailing-List: contact ant-user-help@jakarta.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Help: List-Post: List-Id: "Ant Users List" Reply-To: "Ant Users List" Delivered-To: mailing list ant-user@jakarta.apache.org Received: (qmail 4929 invoked from network); 3 Apr 2002 14:38:09 -0000 X-Authentication-Warning: bodewig.bost.de: bodewig set sender to bodewig@apache.org using -f To: ant-user@jakarta.apache.org Subject: Re: Zip task does not store file size References: <20020318124842.45101.qmail@web20410.mail.yahoo.com> From: Stefan Bodewig Date: 03 Apr 2002 16:37:02 +0200 In-Reply-To: <20020318124842.45101.qmail@web20410.mail.yahoo.com> Message-ID: Lines: 60 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Civil Service) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N On Mon, 18 Mar 2002, Christoph Behnke wrote: > The zip task does not store the uncompressed file size > in the generated zip file. This is not mandatory in > zip file format but other tools like winzip are > storing the uncompressed file size in the zip file. Sorry for taking so long to answer. When I talk about the ZIP format, I'm basing what I say on . The zip classes Ant uses take advantage of the Data Descriptor that one should use if one cannot seek the files being compressed. Java's built-in java.util.zip classes do the same BTW. If you do so, you set "bit 3 of the general purpose bit flag", which again implies >> 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. So Ant is supposed to set these fields in the local file header to 0. Ant *does* store them both in the data descriptor and in the central directory file header - the later is used as the authoritative source by InfoZip. The question that remains is, why does Ant use this feature? Well, you don't know the CRC and the compressed size before you've compressed the file. And in reality you cannot trust File.length() as it may (and will) return bad values on some OSes/JVMs - that means that you don't really know the uncompressed size before you've compressed the file either. Compressing the complete file in memory may be too expensive, so Ant's zip classes (again just like java.util.zip) directly write the data into the archive while they compress the file. As you have to write the local file header before you write the data, Ant doesn't know the size information at this point and cannot insert it. > Is there a possibility to let the ant zip taks store > the file size? It does so at two places and InfoZip based zips (like the one shipping with Linux distributions) can read it: [bodewig@bodewig jakarta-ant]$ unzip -l $ANT_HOME/lib/ant.jar Archive: /home/bodewig/ASF/jakarta/jakarta-ant/bootstrap/lib/ant.jar Length Date Time Name -------- ---- ---- ---- 0 04-03-02 15:10 META-INF/ 439 04-03-02 15:10 META-INF/MANIFEST.MF [snip] so WinZIP isn't doing as good as it could 8-) Stefan -- To unsubscribe, e-mail: For additional commands, e-mail: