{
  "WorkItem": {
    "AffectedComponent": {
      "Name": "",
      "DisplayName": ""
    },
    "ClosedComment": "fixed in v1.9.0.31 and later, or v1.8.4.29 and later.",
    "ClosedDate": "2009-12-18T12:29:34.263-08:00",
    "CommentCount": 0,
    "Custom": null,
    "Description": "Having created a ZipEntry, I am setting the CompressionMethod to Store (0), therefore expecting that this entry will not be compressed when the archive is saved. However, the entry is compressed as normal.\n \nWhat appears to be happening is that the ZipEntry is created with the private member _CompressionMethod defaulting to zero. The setter for CompressionMethod then does a quick check to see if the requested compression method (value) is different from the existing method (_CompressionMethod). In this case, both values are zero, so the setter immediately exits (nothing to do). Unfortunately, it does so before it has had time to set _ForceNoCompression. With this not set, the ZipEntry.Write method uses the default compression for the archive, Deflate (8).",
    "LastUpdatedDate": "2013-05-16T05:31:58.993-07:00",
    "PlannedForRelease": "",
    "ReleaseVisibleToPublic": false,
    "Priority": {
      "Name": "Low",
      "Severity": 50,
      "Id": 1
    },
    "ProjectName": "DotNetZip",
    "ReportedDate": "2009-11-18T07:46:22.14-08:00",
    "Status": {
      "Name": "Closed",
      "Id": 4
    },
    "ReasonClosed": {
      "Name": "Unassigned"
    },
    "Summary": "ZipEntry.CompressionMethod ignored",
    "Type": {
      "Name": "Issue",
      "Id": 3
    },
    "VoteCount": 1,
    "Id": 9208
  },
  "FileAttachments": [],
  "Comments": [
    {
      "Message": "Thanks for reporting this.  This is in v1.8, correct? \r\nJust FYI - I believe this is not a problem in v1.9.  Try it and see.",
      "PostedDate": "2009-11-18T13:30:03.857-08:00",
      "Id": -2147483648
    },
    {
      "Message": "Check that - I just looked at this again, and it is a problem in v1.9, as well as v1.8.  I had a test for this condition, but it wasn't well designed.  I have a fix.  It will be in v1.9.0.31 and v1.8.4.29.  As a workaround, you can set CompressionLevel to CompressionLevel.None. ",
      "PostedDate": "2009-11-19T07:20:51.247-08:00",
      "Id": -2147483648
    },
    {
      "Message": "Sorry, I shold have mentioned the version. I'm using the Reduced dll at version 1.8.4.24.\r\n\r\nAs it happens, I don't need a work-around, as I always want compression, but I was curious to see why I was getting it when a bug in my own code meant I wasn't asking for it, or rather I was asking for no compression by mistake.\r\n\r\nThanks for a quick response as ever.\r\n",
      "PostedDate": "2009-11-20T01:22:04.12-08:00",
      "Id": -2147483648
    },
    {
      "Message": "Excellent - thanks for the reply.  I'll close this one out when I post those releases.",
      "PostedDate": "2009-11-20T09:55:34.217-08:00",
      "Id": -2147483648
    },
    {
      "Message": "",
      "PostedDate": "2009-12-18T12:29:34.263-08:00",
      "Id": -2147483648
    },
    {
      "Message": "",
      "PostedDate": "2013-02-21T18:43:47.583-08:00",
      "Id": -2147483648
    },
    {
      "Message": "",
      "PostedDate": "2013-05-16T05:31:58.993-07:00",
      "Id": -2147483648
    }
  ]
}