{
  "WorkItem": {
    "AffectedComponent": {
      "Name": "",
      "DisplayName": ""
    },
    "ClosedComment": "",
    "ClosedDate": null,
    "CommentCount": 0,
    "Custom": null,
    "Description": "Attached is a project which reliably produces an invalid zip file.  It adds a particular single file to a zip file and then extracts the file back out of the zip file.  It does this 10 times, out of which you may expect to get 5-7 different corrupt zip files!  I have only seen this happen with the particular file that is being compressed in the attached project.",
    "LastUpdatedDate": "2014-12-29T07:04:46.873-08:00",
    "PlannedForRelease": "",
    "ReleaseVisibleToPublic": false,
    "Priority": {
      "Name": "Unassigned",
      "Severity": 0,
      "Id": 0
    },
    "ProjectName": "DotNetZip",
    "ReportedDate": "2014-11-04T19:07:24.57-08:00",
    "Status": {
      "Name": "Proposed",
      "Id": 1
    },
    "ReasonClosed": {
      "Name": "Unassigned"
    },
    "Summary": "Produces corrupt zip file",
    "Type": {
      "Name": "Unassigned",
      "Id": 5
    },
    "VoteCount": 1,
    "Id": 17103
  },
  "FileAttachments": [
    {
      "FileId": 4929,
      "FileName": "IonicZipBug.zip",
      "DownloadUrl": ".\\4929"
    }
  ],
  "Comments": [
    {
      "Message": "The file size of your test file ((1507328) is a multiple of the default internal dotnetziplib buffer size (64kb) which unfortunately exposes it to the dreaded and unpredictable ParallelDeflate optimization bug (https://dotnetzip.codeplex.com/workitem/14087). To test if this bug is the cause of your problem, set  zip.ParallelDeflateThreshold = -1 before saving the zip file. This completely disables the ParallelDeflate (multithreaded) optimization. If that setting gives reliable results for you, you can use it as a work-around or if you are interested in fixing the bug in your own copy of the DotNetZipLib, look carefully at the comments on that bug and make the fix so that you can safely use the ParallelDeflate optimization. Obviously, the official DotNetZipLib codebase is not being maintained at this time or that bug would be fixed by now.",
      "PostedDate": "2014-11-05T06:17:22.617-08:00",
      "Id": -2147483648
    },
    {
      "Message": "The ParallelDeflateThreshold did not fix my corrupt zip. Somehow the zip is not corrupt with winrar 5.20 but it is corrupt with the windows 8.1 default zip option.\nboth with ParallelDeflateThreshold = -1  as without",
      "PostedDate": "2014-12-22T03:15:50.207-08:00",
      "Id": -2147483648
    },
    {
      "Message": "Odd...I ran your project as it is coded and I see the 10 diagnostic lines giving the CRC from the entry and the CRC from the reader and, as you say, for many (most) of the lines, the CRC from the entry does not match the CRC from the reader.\r\n\r\nI then added \r\n\r\nzipFile.ParallelDeflateThreshold = -1;\r\n\r\nbetween the zipFile.AddFile() and zipFile.Save() statements and when I run the program all 10 lines give the same CRC for the entry and the reader. So this is demonstrating the bug and the work-around that I suggested.",
      "PostedDate": "2014-12-29T07:04:46.873-08:00",
      "Id": -2147483648
    }
  ]
}