This is an update to my zip library and utility.  You can read previous entries on this here

[Update 30 October 2007]: I moved this library to a CodePlex project. See www.codeplex.com/DotNetZip  It has been steadily improved since the time of this post. 

A reader mailed me to say that the Zip library did not work with some zip archives.  I knew that would be true.  The zip library code I had originally posted does not handle all zip files.  The zip spec is pretty rich, and has a bunch of advanced features.  The simple DotNetZip library I produced intially did not support them all. 

But this particular reader had a pretty simple request. They needed support for the Data Descriptor field when reading a zip archive.  

There's a part of the PKZIP spec that allows the compressed and uncompressed size of the files, and the CRC, to be placed after the actual compressed file data within the zip archive, in what the spec calls a "Data Descriptor".  This is to support zip creation where the output stream does not support streaming.  The presence of the Data Descriptor is flagged in a zip file when the "BitField" for a Zip entry has bit 3 set.  The current APPNOTE from PKWare says:

This descriptor exists only if bit 3 of the general purpose bit flag is set (see below). It is byte aligned and immediately follows the last byte of compressed data. This descriptor is used only when it was not possible to seek in the output .ZIP file, e.g., when the output .ZIP file was standard output or [another] non-seekable device. 

The person who emailed me also gave a zip archive that included this data descriptor, and asked "why can't your library read this zip?".  Using that as a test case, I've updated the Zip library to support the Data Descriptor for reading/extracting.  It will work correctly now, upon reading such archives. 

Keep in mind that DotNetZip, the zip library implementation I built,  is not a streaming implementation, so it will never produce (write) a zip archive that includes a Data Descriptor like this.  [update:  this is no longer true, as of 2008]  It will produce zips that are interoperable with winzip and pkzip, as well as the Java JAR tool, etc.  

[update: See the codeplex project for source code ]