{ "WorkItem": { "AffectedComponent": { "Name": "", "DisplayName": "" }, "ClosedComment": "fixed in changeset 53628. First binary v1.8.4.29, or v1.9.0.36. ", "ClosedDate": "2010-01-05T11:01:43.773-08:00", "CommentCount": 0, "Custom": null, "Description": "I'm getting an array index out of bounds exception on some zip files on this line\n \nusing (ZipFile zip = ZipFile.Read(zipProjectFile))\n \n \nThe strange thing is, all normal zip programs read the files without any errors. The only thing they have in common is that their contents were altered and updated in batch mode with both PowerGREP and WinRAR. However, I can't yet reproduce this by batching new zip files with these programs, although I haven't done this very exhaustively yet. If I open and resave the zips the problem goes away. Unfortunately, the originals have already been distributed (and they're working fine) and ideally I'd like to have the utility I'm working on to be able to process the distributed versions of the files without having to get all my users to update...\n \nAny ideas what might be going on here? I'd be happy to send an example.", "LastUpdatedDate": "2013-05-16T05:31:56.583-07:00", "PlannedForRelease": "", "ReleaseVisibleToPublic": false, "Priority": { "Name": "Low", "Severity": 50, "Id": 1 }, "ProjectName": "DotNetZip", "ReportedDate": "2010-01-04T11:09:52.05-08:00", "Status": { "Name": "Closed", "Id": 4 }, "ReasonClosed": { "Name": "Unassigned" }, "Summary": "Index out of bounds in FixZipDirectory, reading broken zips", "Type": { "Name": "Issue", "Id": 3 }, "VoteCount": 1, "Id": 9912 }, "FileAttachments": [ { "FileId": 2593, "FileName": "FixZip.cs.snip", "DownloadUrl": ".\\2593" } ], "Comments": [ { "Message": "Hi Cheeso,\r\n\r\nThanks for the quick response! I'm attaching two versions of the same package, one that works and one that throws the index out of bounds error when I try to read it with dotnetzip. Note that both files are actually regular zips, even though their extension is .hmskin (they are skin pack files for Help & Manual documentation projects).", "PostedDate": "2010-01-04T23:02:59.627-08:00", "Id": -2147483648 }, { "Message": "", "PostedDate": "2010-01-04T23:03:03.373-08:00", "Id": -2147483648 }, { "Message": "Here's the one that is OK after being rezipped. The error version was updated in batch mode with WinRAR and PowerGREP, using the standard zip compression settings in both those programs.", "PostedDate": "2010-01-04T23:04:21.32-08:00", "Id": -2147483648 }, { "Message": "", "PostedDate": "2010-01-04T23:04:23.367-08:00", "Id": -2147483648 }, { "Message": "PS: These are from a commercial product so I'd be grateful if you'd delete the files as soon as you've received them. ", "PostedDate": "2010-01-04T23:05:29.65-08:00", "Id": -2147483648 }, { "Message": "It's too early in the morning: The library version is the current stable version, 1.8. ", "PostedDate": "2010-01-04T23:06:53.92-08:00", "Id": -2147483648 }, { "Message": "ok I reproduced the error here.\r\n", "PostedDate": "2010-01-05T09:22:01.283-08:00", "Id": -2147483648 }, { "Message": "", "PostedDate": "2010-01-05T09:22:11.33-08:00", "Id": -2147483648 }, { "Message": "", "PostedDate": "2010-01-05T09:22:19.85-08:00", "Id": -2147483648 }, { "Message": "ok Tim, I looked into it. The \"error\" skinpack file is corrupted. Whatever update you made with WinRar and Powergrep didn't work. It corrupts the \"Central directory\", and that is what's causing the DotNetZip to choke. There's a fixup capability in DotNetZip available via the static method ZipFile.FixZipDirectory(). But when I tried that method on your file, it still failed. Turns out the implementation of FixZipDirectory is less resilient than it should be. So, I corrected *that* in v1.9.0.36 of DotNetZip. (also v1.8.4.29) and so, if you grab one of those new releases, then call ZipFile.FixZipDirectory() on your zipfile, and THEN try reading it with ZipFile.Read(), it should work fine. \r\n\r\nThe other way to fix your problem is avoid the corruption in the first place. In case you wanna do that, here's what I found: The corruption in the zip directory was detected in the \"extra\" field in the central directory for the 2nd zip entry - but just based on a quick look, it was present throughout the central directory. In the 2nd zip entry, the length of the \"Extra Field\" was listed as 4a bytes, but there was no \"extra field\" data present. This was consistent through the rest of the directory entries. \r\n\r\nSummary: your \"error\" zip was corrupted. Based on that, DotNetZip's failure to read it is expected. There's a \"manual\" fixup capability in DotNetZip that should have worked but didn't. I fixed that. Now you can use FixZipDirectory() on your zip to un-corrupt it. \r\n", "PostedDate": "2010-01-05T10:49:38.463-08:00", "Id": -2147483648 }, { "Message": "Here's some code that shows how I called the ZipFixDirectory() method on your file.\r\n", "PostedDate": "2010-01-05T10:58:00.923-08:00", "Id": -2147483648 }, { "Message": "", "PostedDate": "2010-01-05T10:58:02.573-08:00", "Id": -2147483648 }, { "Message": "", "PostedDate": "2010-01-05T11:01:16.58-08:00", "Id": -2147483648 }, { "Message": "", "PostedDate": "2010-01-05T11:01:43.773-08:00", "Id": -2147483648 }, { "Message": "Cheeso, thank you very much for checking this in such detail and providing the fix! Now I'm going to have to do some extensive testing to find out just where in the batch process this is happening, or if it was just a once-off thing. In the short term I may just have to build a small utility with FixZipDirectory() and include it in the batch process... :-/\r\n\r\nThanks again and Happy New Year!", "PostedDate": "2010-01-05T20:43:21.117-08:00", "Id": -2147483648 }, { "Message": "Cheeso, a quick update on this after testing: The version of FixZipDirectory() in v1.8.4.29 doesn't work at all on any of the problem files -- it throws an exception saying that they're not valid zip files. The version in v1.9.0.36 does work, but not on all problem files -- strangely, it doesn't work on the one I sent you, although it does work on others. When it doesn't work it just fails silently, so that's OK. I can work around that, in the few cases where it doesn't work I can then catch the error on the read attempt after the failed fix and ask users to open and resave the file once, then the problem is solved.\r\n\r\nI'm sure the corruption is genuine, but it's still notable that dotnetzip is the only application I can find that has a problem with it. It's completely transparent to WinRAR, WinZip, PowerGREP, TotalCommander, pkZip/Unzip and the integrated unzip routines in Mac OS X Leopard, Windows 7, Windows Vista and Windows XP. \r\n\r\nThanks again for all your help -- now at least I have a workable workaround. ;-)", "PostedDate": "2010-01-05T22:19:14.427-08:00", "Id": -2147483648 }, { "Message": "", "PostedDate": "2013-02-21T18:43:44.637-08:00", "Id": -2147483648 }, { "Message": "", "PostedDate": "2013-05-16T05:31:56.583-07:00", "Id": -2147483648 } ] }