This project is read-only.

Predicting Zip Archive Length and the Mac Finder

Jul 6, 2011 at 9:28 PM

I need to predict the length of a ZIP archive BEFORE I begin the process of generating an output stream.  Individual files are being streamed from a remote server.  It is adequate in my application that the ZIP archive contain uncompressed files.

I have successfully created a ZIP archive size calculator which will calculate the correct size of a resulting ZIP archive given the path name and size of each file in the archive AND setting CompressionLevel == 'None'.  I can calculate the size of the archive BEFORE it is generated and the calculated size exactly matches the generated size of the archive.  The calculator accounts for file headers and descriptors, and directory meta data.

This generally works as expected, at least on computers which do not have illuminated pictures of half eaten fruit on the cover.  These archives will NOT work with the Mac OS Finder application.  It is well documented that the Finder application on the Mac OS does not support ZIP archives containing uncompressed files.  Why this is the case, only Steve and his minions can know.

What DOES work on the Mac OS is a 'DEFLATE'd ZIP archive with NO underlying compression.  In such a case, the corresponding ZIP archive (should) contain a DEFLATEd stream with ~64k (- 1) 'chunks' with 5 byte buffer separators containing buffer lengths.  In theory, one should be able to accurately predict the size of such an archive.  The only difference being to compute the number of chunks and account for an appropriate number of 5 byte buffer separators.


1)  Is there a way using DotNetZipLib to create an output stream that contains a 'DEFLATE'd stream with NO compression?

2)  If so, can the ~64k ( - 1) buffer boundaries be ACCURATELY predicted so as to accurately compute the size of the streamed image for each file in the ZIP archive?

3)  Is there any other way to generate a Mac Finder compatible ZIP archive containing otherwise uncompressed data (for which the size of the archive is predictable)?

Any help or ideas would be greatly appreciated.


(no Klein bottles please)

Jul 7, 2011 at 7:13 PM

1. No - in DotNetZip, there is no way to use compression and get a non-compressed stream, or a stream sliced into chunks delimited by the 5-byte segment separators. I suppose you could write that yourself if its important to you.

2.  if you wrote something, then I guess you could accurately predict the size.

3. I can't imagine another way.


I find myself wondering why you need to predict the size of the archive. Maybe there is a way to wiggle out of that requirement, which would then allow you to use compression.