{ "WorkItem": { "AffectedComponent": { "Name": "", "DisplayName": "" }, "ClosedComment": "Not a bug. Pilot error. ", "ClosedDate": "2011-03-20T06:45:57.197-07:00", "CommentCount": 0, "Custom": null, "Description": "After trying every possible combination of ending the response with or without flushing I ended up with variations of corruption.\n \nAfter a bit more research, it occurred to me to setting BufferOutput to false may have been the cause of the issue. I commented\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.\n \nMy 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?", "LastUpdatedDate": "2013-05-16T05:31:41.893-07:00", "PlannedForRelease": "", "ReleaseVisibleToPublic": false, "Priority": { "Name": "Low", "Severity": 50, "Id": 1 }, "ProjectName": "DotNetZip", "ReportedDate": "2010-11-11T04:24:59.453-08:00", "Status": { "Name": "Closed", "Id": 4 }, "ReasonClosed": { "Name": "Unassigned" }, "Summary": "Corrupt File Zip with no Extension", "Type": { "Name": "Issue", "Id": 3 }, "VoteCount": 1, "Id": 12466 }, "FileAttachments": [ { "FileId": 3669, "FileName": "ScreengrabAndArchive.zip", "DownloadUrl": ".\\3669" } ], "Comments": [ { "Message": "If it would be helpful, I can put together a sample replication of the process on the web server, send you the exact code and allow you to run some tests. I can not be sure the bug has been resolved until I can confirm that customers no longer receive corrupt files. It works on my machine :-)", "PostedDate": "2010-11-11T06:28:28.85-08:00", "Id": -2147483648 }, { "Message": "", "PostedDate": "2010-12-15T15:01:45.59-08:00", "Id": -2147483648 }, { "Message": "I am having the same problem where it works fine on my local machine but comes up with \"unexpected end of archive\" error in WinRar (it doesnt work in WinZip or windows built in zip either but the error message is less explicit). Having had the problem on my own page i thought i would test it with the \"GenerateZip-Csharp.aspx\" example page. Other than changing the directory to list and add files from, and fixing an error in the line \"zip.AddEntry(\"Readme.txt\", \"\", ReadmeText, Encoding.Default);\" - no method takes four parameters, so changed to zip.AddEntry(\"Readme.txt\", ReadmeText) - its exactly the same. However, the same thing happened - i.e. it works fine on my local development machine, but running it on the live server had the problem.\r\n\r\nI have attached a zip including a screengrab of what happens and the archive that was returned in the hope that might help.", "PostedDate": "2010-12-15T15:01:47.83-08:00", "Id": -2147483648 }, { "Message": "Hi,\r\n\r\nIf you're using Response.Close then that might be the cause of the problem. Response.Close basically pulls the rug out from under the connection, cancels any buffered data, and tells the client browser to stop listening for incoming data.\r\n\r\nAs I understand it, even if you call Response.Flush, it means that if there's any network latency you might find the \"Response.Close\" packet arrives at the browser before the last block of response data. In this case the browser will stop the download before it reads all the data. I'm guessing that your local test is probably avoiding any latency so the \"Response.Close\" arrives after the download has completed.\r\n\r\nI believe this situation can be avoided by using HttpApplication.CompleteRequest instead of Response.Close. You can then use BufferOutput = true or false as you see fit.\r\n\r\nSee http://dotnetzip.codeplex.com/Thread/View.aspx?ThreadId=238541 for a similar problem...\r\n\r\nCheers,\r\n\r\nMike", "PostedDate": "2010-12-16T07:23:47.307-08:00", "Id": -2147483648 }, { "Message": "HttpContext.Current.ApplicationInstance.CompleteRequest(); instead of Response.Close(); has done the trick. Excellent stuff - thank you very much. Obviously, latency isnt an issue when you are testing it on your local machine so the reset packet arrives in the right order - if you are runnning it on a server on another continent (as i am), the reset packet always arrived before the end of the zip file so it never worked. And there was me thinking that we'd moved past the point that \"network issues\" had a major impact on web application development years ago!", "PostedDate": "2010-12-16T13:26:05.73-08:00", "Id": -2147483648 }, { "Message": "Same thing happening to me - I've tried a myraid of things listed in other posts with similar problems. No joy.\r\nAnyone have something to add at this point - I'm up for trying anything. Thanks!", "PostedDate": "2011-01-10T19:48:28.31-08:00", "Id": -2147483648 }, { "Message": "I just found the fix inadvertently.\r\n\r\nIn this page, http://cheeso.members.winisp.net/DotNetZipHelp/Example-ASPNET.htm - I found that he was doing a response.clear and response.end. After I added both in, the corruption stopped. So it looks like:\r\n\r\n// multi-line\r\n{{\r\n Response.Clear()\r\n Response.ContentType = \"application/zip\"\r\n Response.AddHeader(\"Content-Disposition\", \"filename=\" & Format(Now, \"yyyy-MM-dd hhmmss\") & \".zip\")\r\n\r\n Using zip As New ZipFile\r\n\r\n For Each file As String In System.IO.Directory.GetFiles(Server.MapPath(\"~/Files/\"))\r\n zip.AddFile(file, \"\")\r\n Next\r\n\r\n zip.Save(Response.OutputStream)\r\n\r\n End Using\r\n\r\n Response.End()\r\n}}\r\n\r\n", "PostedDate": "2011-01-10T20:10:45.783-08:00", "Id": -2147483648 }, { "Message": "Hi jreynolds,\r\n\r\nYou should really use HttpContext.CompleteRequest instead of Response.End as it's a cleaner route.\r\n\r\nSee http://dotnetzip.codeplex.com/Thread/View.aspx?ThreadId=238541 for a similar problem and some technical references for why it's preferred...\r\n\r\nCheers,\r\n\r\nM\r\n\r\n", "PostedDate": "2011-01-11T00:49:51.43-08:00", "Id": -2147483648 }, { "Message": "", "PostedDate": "2011-03-20T06:45:57.197-07:00", "Id": -2147483648 }, { "Message": "", "PostedDate": "2013-02-21T18:43:22.997-08:00", "Id": -2147483648 }, { "Message": "", "PostedDate": "2013-05-16T05:31:41.893-07:00", "Id": -2147483648 } ] }