Cannot assume necessary data is in Local File Header about node-unzip HOT 5 CLOSED

So in some cases the Central Directory File Header includes the compressed and uncompressed sizes of the files in the zip file? If you're able, can you send a link to an example zip file, or can you suggest a free tool that creates this type of zip?

from node-unzip.

Here's an example created with the java jar command line tool: http://cl.ly/0E3S0A2o0D2b/test.zip

I think this is the same problem. Local file header has 0 as compressed and uncompressed sizes. Central Directory File Header has the actual sizes.

from node-unzip.

Interestingly, the pullstream.pipe() to Inflater deflates the first entry, but never emits the 'end' event. Instead it loops indefinitely processing zero bytes. I think this can be made to work without having to read the central directory data at the end of the stream if that condition that causes it to loop indefinitely can instead be detected and trigger the 'end' event.

from node-unzip.

the parser always parsed front to back which does not work with the case of bit 3 set
as defined in http://www.pkware.com/documents/casestudies/APPNOTE.TXT

   4.4.4 general purpose bit flag: (2 bytes)

   ...

    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.)

i would assume it might work to just read the directory once into memory and then reading forward through the file.

is somebody working on this or do we need to fork ?

from node-unzip.

@EvanOxfeld The Archive Utility in Mac OS X writes zip archives this way by default, I believe, as do most streaming implementations, since they can write the Local File Header without knowing the compressed size ahead of time. If you're creating large zip archives, or archives containing large files, it's pretty much the only way to go.

@matthiasg I had enough trouble finding robust bi-directional zip archive support, and needed it for a production system, so I ended up writing my own. It's not open source yet, but should be soon.

from node-unzip.