This project is read-only.

Zip file is different if saved to stream vs. a file

Apr 19, 2010 at 5:58 PM

I have an issue where the zip file I generate is different depending on whether I save it to a file or save it to a stream.

I'm basically building a zip file that will be a Windows gadget.  (gadget files are just zips)  The gadget file is built on-the-fly using DotNetZip and sent to the user.

If I just have the code save the zip to a local file and I double-click it, I can install the gadget without issue.  But if I save the gadget to Response.OutputStream and try to open it (whether I open it from the browser or save it and then open it) Windows won't install the gadget - it says it is not a valid gadget file.

I can open up both files with 7Zip and they look indentical.  In fact if I unzip it and zip up those files, it'll build a gadget file that'll work.  But the file saved to disk is about 80 characters larger than the one saved to the stream.

Any ideas what could be wrong?  Whatever the difference is, it doesn't seem to matter to 7zip but it does to Windows as it tries to process the gadget file.

BTW I'm running Windows 7 x64.  Tested with both IE and Firefox.


Apr 19, 2010 at 6:27 PM
Edited Apr 19, 2010 at 6:28 PM

Hi ronmichael,

It might be the same problem as this workitem...

If you've downloaded the source code, try changing the following line in Zlib.ZlibBaseStream.Read. If you get an exception thrown there it's the same issue - the zlib stream isn't flushing all the data out before it quits.

Replace this:

if (nomoreinput && _wantCompress) return 0; // workitem 8557


if (nomoreinput && _wantCompress)
if (_z.dstate.pendingCount > 0) throw new System.InvalidOperationException();
return 0; // workitem 8557

Hope this helps,


Apr 21, 2010 at 5:07 PM

I'll bet the problem is with "bit 3".  Bit 3 is an option in the zip spec that was designed to support writing zips into output streams. 

If you use DotNetZip to write to a non-seekable output stream, like the ASPNET Response.OutputStream , then you'll get bit 3 turned on in your zip file.  If you use DotNetZip to write to a file, you don't get bit 3.

I don't know the requirements on gadget files, so this is just a guess. 


Apr 22, 2010 at 1:55 PM

Mike and Cheeso - thank you for your very helpful comments and suggestions.  I think Cheeso got it.  I wasn't aware of the Bit 3 option or that zips written to a stream would be different from those written to a file.  But that appears to explain it.  A Windows gadget file is just supposed to be a collection of files in a ZIP or CAB with the extension changed to .gadget but apparently Microsoft must not have a very sophisticated unzip mechanism for it.  I've since switched to building a CAB (as I want to be able to sign the gadget, and only a cab can be signed) and found that even the order of the files in the cabinet makes a difference.

Anyway, thank you both!