[
  {
    "Id": "432779",
    "ThreadId": "209799",
    "Html": "<p>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.</p>\r\n<p>I'm basically building a zip file that will be a Windows gadget.&nbsp; (gadget files are just zips)&nbsp; The gadget file is built on-the-fly using DotNetZip and sent to the user.</p>\r\n<p>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.&nbsp; 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.</p>\r\n<p>I can open up both files with 7Zip and they look indentical.&nbsp; In fact if I unzip it and zip up those files, it'll build a gadget file that'll work.&nbsp; But the file saved to disk is about 80 characters larger than the one saved to the stream.</p>\r\n<p>Any ideas what could be wrong?&nbsp; 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.</p>\r\n<p>BTW I'm running Windows 7 x64.&nbsp; Tested with both IE and Firefox.</p>\r\n<p>Thanks!</p>",
    "PostedDate": "2010-04-19T09:58:31.327-07:00",
    "UserRole": null,
    "MarkedAsAnswerDate": null
  },
  {
    "Id": "432787",
    "ThreadId": "209799",
    "Html": "<p>Hi ronmichael,</p>\r\n<p>It might&nbsp;be the same problem as this workitem...</p>\r\n<p><a href=\"http://dotnetzip.codeplex.com/WorkItem/View.aspx?WorkItemId=10562\">http://dotnetzip.codeplex.com/WorkItem/View.aspx?WorkItemId=10562</a></p>\r\n<p>If you've downloaded the source code, try changing the following&nbsp;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.</p>\r\n<p>Replace this:</p>\r\n<p>if (nomoreinput &amp;&amp; _wantCompress) return 0; // workitem 8557<br><br>with<br><br>if (nomoreinput &amp;&amp; _wantCompress)<br>{<br>if (_z.dstate.pendingCount &gt; 0) throw new System.InvalidOperationException();<br>return 0; // workitem 8557<br>}</p>\r\n<p>Hope this helps,</p>\r\n<p>Mike</p>",
    "PostedDate": "2010-04-19T10:27:55.737-07:00",
    "UserRole": null,
    "MarkedAsAnswerDate": null
  },
  {
    "Id": "433731",
    "ThreadId": "209799",
    "Html": "<p>I'll bet the problem is with &quot;bit 3&quot;.&nbsp; Bit 3 is an option in the zip spec that was designed to support writing zips into output streams.&nbsp;</p>\r\n<p>If you use DotNetZip to write to a non-seekable output stream, like the ASPNET Response.OutputStream&nbsp;, then&nbsp;you'll get bit 3 turned on in your zip file.&nbsp; If you use DotNetZip to write to a file, you don't get bit 3.</p>\r\n<p>I don't know the requirements on gadget files, so this is just a guess.&nbsp;</p>\r\n<p>&nbsp;</p>",
    "PostedDate": "2010-04-21T09:07:55.59-07:00",
    "UserRole": null,
    "MarkedAsAnswerDate": null
  },
  {
    "Id": "434177",
    "ThreadId": "209799",
    "Html": "<p>Mike and Cheeso - thank you for your very helpful comments and suggestions. &nbsp;I think Cheeso got it. &nbsp;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. &nbsp;But that appears to explain it. &nbsp;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. &nbsp;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.</p>\r\n<p>Anyway, thank you both!</p>\r\n<p>&nbsp;</p>\r\n<p>&nbsp;</p>\r\n<p>&nbsp;</p>",
    "PostedDate": "2010-04-22T05:55:46.53-07:00",
    "UserRole": null,
    "MarkedAsAnswerDate": null
  }
]