[ { "Id": "519648", "ThreadId": "234089", "Html": "\r\n

Hello

\r\n

I am using the AddDirectory method to add several folders to a zip file. I then save the zip file to the output stream. I have some users complaining of corrupt zip files.

\r\n

I also get the error when I manually test the app on the server, however, when I debug the code locally I cannot recreate the issue.

\r\n

I found a discussion thread that was on point (Thread 64325). I am having the same type of issue, but I definitely never "accidentally" created a zip that I am adding to the new zip. After downloading, when using Windows standard unzip program,\r\n I will get a corrupt file error. If I use WinRar, I find a file with no file extension. If I rename it and give it a zip extension everything is there.

\r\n

Any ideas?

\r\n

\r\n
\r\n
try\r\n        {\r\n            Models.StoreOrder order = (Models.StoreOrder)Session["Order"];\r\n            BL.StoreManager Store = new BL.StoreManager();\r\n\r\n\r\n            Response.Clear();\r\n            Response.BufferOutput = false; // no buffering - allows large zip files to download as they are zipped \r\n            string ReadmeText = Store.GetDownloadReadMe(order.ObjectsInOrder) + " " + DateTime.Now.ToString("G");\r\n            string archiveName = String.Format("Wisc-Online-{0}.zip", DateTime.Now.ToString("yyyy-MMM-dd-HHmmss"));\r\n            Response.ContentType = "application/zip";\r\n            Response.AddHeader("content-disposition", "attachment; filename=" + archiveName);\r\n\r\n            using (ZipFile zip = new ZipFile())\r\n            {\r\n                zip.AddEntry("Readme.txt", ReadmeText);\r\n\r\n                foreach (Models.Object o in order.ObjectsInOrder)\r\n                {\r\n                    System.IO.DirectoryInfo dir = new System.IO.DirectoryInfo(Server.MapPath("/Objects/" + o.ID));\r\n                    zip.AddDirectory(dir.FullName, dir.Name);\r\n\r\n                }\r\n\r\n                zip.Save(Response.OutputStream);\r\n            }\r\n            Session["Order"] = null;\r\n        }\r\n        catch (Exception ex)\r\n        {\r\n            BL.SiteManager sm = new BL.SiteManager();\r\n            sm.SendEmailToWebmaster(BL.SharedConstants.WEBMASTEREMAIL, ex.StackTrace.ToString() + ex.Message, "Download exception");\r\n            throw;\r\n        }\r\n        finally\r\n        {\r\n            HttpContext.Current.ApplicationInstance.CompleteRequest();\r\n        }\r\n\r\n
\r\n
\r\n

\r\n", "PostedDate": "2010-11-09T15:25:21.967-08:00", "UserRole": null, "MarkedAsAnswerDate": null }, { "Id": "519715", "ThreadId": "234089", "Html": "\r\n

Yes.

\r\n

Try this:  remove the call to HttpContext.Current.ApplicationInstance.CompleteRequest(), and replace it with Response.Close().

\r\n

There was a time when a sample shipped with that CompleteRequest in it, but that is wrong. I have since discovered that using it can result in corrupt zip files. You should use Response.Close() instead.

\r\n

 

\r\n", "PostedDate": "2010-11-09T18:17:50.957-08:00", "UserRole": null, "MarkedAsAnswerDate": null }, { "Id": "519720", "ThreadId": "234089", "Html": "\r\n

Thank you for replying. I use this library in a few apps and I really like working with it.  In the other apps, I am zipping on the fly client side and uploading to the server. Works like a charm.

\r\n

 

\r\n

Response.Close() resulted in a definite corrupt zip. This time around even WinRar throws an error when unzipping - unexpected end of archive.  Could this be caused by the Response ending abrupt;y before the process is finished? It all happens\r\n on the same thread so I am not sure if that is possible. Perhaps I shouldn't make assumptions there. Is the process asynch?

\r\n

 

\r\n

C:\\Users\\stulo.FVTC\\Desktop\\Wisc-Online-2010-Nov-09-202621.zip: Unexpected end of archive!  \r\n
\r\nC:\\Users\\stulo.FVTC\\Desktop\\Wisc-Online-2010-Nov-09-202621.zip: CRC failed in Wisc-Online-2010-Nov-09-202621. The file is corrupt

\r\n

 

\r\n

 

\r\n", "PostedDate": "2010-11-09T18:36:19.277-08:00", "UserRole": null, "MarkedAsAnswerDate": null }, { "Id": "520071", "ThreadId": "234089", "Html": "\r\n

Hmm, that's interesting.  Reliable corruption using Response.Close(). 

\r\n

No, the Save process won't be asynchronous.  When Save() returns, it's done.

\r\n

You could try Response.End() in place of Response.Close().  You could also try Response.Flush before Response.Close().

\r\n

I don't know what else to suggest - try a few of these combinations and see if you can get it working. let me know.

\r\n

 

\r\n", "PostedDate": "2010-11-10T09:28:40.857-08:00", "UserRole": null, "MarkedAsAnswerDate": null }, { "Id": "520140", "ThreadId": "234089", "Html": "\r\n

After trying every possible combination of ending the response with or without flushing I ended up with variations of corruption.

\r\n

After a little digging, I found out that Response.Flush is only necessary if not buffering the response. After a bit more research, it occurred to me to setting BufferOutput to false may have been the cause of the issue. I commented\r\n out that line and the files downloaded intact. So as I understand it, now the user will have to wait for the entire zip to finish before the download begins. I can live with that.

\r\n

My theory is that somehow allowing the download to start as the zip was processed, caused the error. It know for sure now that it is all the same thread but... possibly a race condition?

\r\n

 

\r\n", "PostedDate": "2010-11-10T11:32:07.983-08:00", "UserRole": null, "MarkedAsAnswerDate": null }, { "Id": "520500", "ThreadId": "234089", "Html": "\r\n

I couldn't judge the cause unless I was able to see the zip files produced in each case. or reproduce it here.  Your understanding is correct - buffering usually means the entire response is buffered before IIS begins to transmit the first byte to the\r\n requester. For a large zip this can be a large problem.  For smaller zips, no problem.  The other side effect is, of course, memory usage on the server. If you have many concurrent requests, they will ALL buffer their results before sending. This\r\n can cause memory usage to spike.  Test to be sure.  

\r\n

Regarding the differences in generating zips with buffering and without....Zips written to non-seekable streams use a slightly different format than those written to seekable streams. When you turn buffering off, Response.OutputStream becomes non-seekable,\r\n and DotNetZip uses the slightly different metadata format (described in some other locations as "bit 3 encoding" - check the zip spec for what this means). Some zip utilities do not properly read bit-3 encoded zip files.  One notable example is, I think,\r\n the built-in zip handling in MacOs.  It will classify such a zip file as corrupted, though other tools can read and extract the zip just fine. WinZip has never exhibited a problem handling bit-3 zip files, as far as I know.  The DotNetZip tools\r\n and library can read zips with or without bit-3 encoding.

\r\n

if you're happy then I guess it's no problem.   It's troubling to me that turning off buffering gives you corruption, and I'll want to investigate that for myself. But if you're satisfied then I guess this particular issue is closed.

\r\n

thanks for the report.

\r\n

 

\r\n", "PostedDate": "2010-11-11T04:24:41.413-08:00", "UserRole": null, "MarkedAsAnswerDate": null }, { "Id": "520502", "ThreadId": "234089", "Html": "This discussion has been copied to a work item. Click here to go to the work item and continue the discussion.", "PostedDate": "2010-11-11T04:25:33.14-08:00", "UserRole": null, "MarkedAsAnswerDate": null } ]