{
  "WorkItem": {
    "AffectedComponent": {
      "Name": "",
      "DisplayName": ""
    },
    "ClosedComment": "",
    "ClosedDate": null,
    "CommentCount": 0,
    "Custom": null,
    "Description": "After I add A Tiny FS file to a new or existing archive using DotNetZip then attempt to extract it using any zip utility or DotNetZip it fails CRC. Now if I manually create the archive or use another library I do not experience the same issue. The code to reproduce the error is at the link listed below. \nhttps://github.com/jcwrequests/TinyFS.Encryption/blob/master/TinyFS.Encryption.Tests/ZipTests.vb\n\nCheers,\n\nJason Wyglendowski",
    "LastUpdatedDate": "2014-06-07T17:41:58.35-07:00",
    "PlannedForRelease": "",
    "ReleaseVisibleToPublic": false,
    "Priority": {
      "Name": "Unassigned",
      "Severity": 0,
      "Id": 0
    },
    "ProjectName": "DotNetZip",
    "ReportedDate": "2014-04-19T10:28:07.427-07:00",
    "Status": {
      "Name": "Proposed",
      "Id": 1
    },
    "ReasonClosed": {
      "Name": "Unassigned"
    },
    "Summary": "CRC Failure",
    "Type": {
      "Name": "Unassigned",
      "Id": 5
    },
    "VoteCount": 3,
    "Id": 16815
  },
  "FileAttachments": [],
  "Comments": [
    {
      "Message": "Without knowing the particulars of TinyFS, my guess is that you end up compressing files whose sizes are an integral multiple of DotNetZipLib's internal buffer (64K) and when that happens, you are vulnerable to the notorious \"parallel compression algorithm\" bug (https://dotnetzip.codeplex.com/workitem/14087), which has been reported and commented on by several developers unable to believe that its status remained low. There are a number of files (like .msi files) that will cause this bug to surface regularly (though still unpredictably). \r\n\r\nIn order to test whether this bug is the source of your problem, set \"archive.ParallelDeflateThreshold = -1\" prior to archive.Save(). If this is the source of your problem, then this line of code is one work-around for the problem (though with the performance penalty of disabling the optimization). You can also find proposed fixes to the actual DotNetZip sources within this forum.\r\n\r\nI take the time to offer this because I empathize with the extremely high priority that such unpredictable, unexplained loss-of-data behavior is until understanding its cause and a work-around. ",
      "PostedDate": "2014-04-21T06:25:07.44-07:00",
      "Id": -2147483648
    },
    {
      "Message": "Thanks John for the information. I was on vacation last week so I just got the time today to test your suggestion and I am happy to say that it work like a charm. Yes that is strange that this is not a high priority item. I will add a comment to the 14087. Thanks again.\r\n\r\nCheers,\r\n\r\nJason Wyglendowski",
      "PostedDate": "2014-04-28T16:13:01.62-07:00",
      "Id": -2147483648
    },
    {
      "Message": "Still not fixed? It's very weird bug, for some of developers (like me) it appears in production and creates money loss.\nFor just a Zip library, compression is primary feature, and it's expected to work without any issues always.",
      "PostedDate": "2014-06-05T21:18:39.363-07:00",
      "Id": -2147483648
    },
    {
      "Message": "",
      "PostedDate": "2014-06-06T05:46:39.873-07:00",
      "Id": -2147483648
    },
    {
      "Message": "",
      "PostedDate": "2014-06-07T17:41:58.35-07:00",
      "Id": -2147483648
    }
  ]
}