{
  "WorkItem": {
    "AffectedComponent": {
      "Name": "",
      "DisplayName": ""
    },
    "ClosedComment": "fixed in change set 26374.  This will be in the next v1.7 preview release (1.7.1.6), will be in the v1.7 final.",
    "ClosedDate": "2008-11-25T08:59:20.467-08:00",
    "CommentCount": 0,
    "Custom": null,
    "Description": "The OnWriteBlock call (ZipEntry class, line 2316) is made with counter.BytesWritten as first parameter but the second parameter is the SOURCE file length. So the granular events may not be really useful for progression visual state. (10%, 20%, 30%, 40%, 50%.... oupss 100% next step because the file is now totally compressed).\n \nI wonder if it would be better to have a counter, which would be increased by the \"n\" value in the \"while\" block, as first parameter (bytes read from source file so far)? So the progression will always be related to the source file. \"counter.BytesWritten\" is lower than \"n\" when data is compressed but when we calculate the percentage of job done, we do that according to the uncompressed file length. I think that it would be a better calculation if we knew how much bytes have been read so far from source file. Maybe the event may have both information ? (Bytes read so far and bytes written so far ??).",
    "LastUpdatedDate": "2013-05-16T05:32:34.53-07:00",
    "PlannedForRelease": "",
    "ReleaseVisibleToPublic": false,
    "Priority": {
      "Name": "Low",
      "Severity": 50,
      "Id": 1
    },
    "ProjectName": "DotNetZip",
    "ReportedDate": "2008-11-25T08:54:17.843-08:00",
    "Status": {
      "Name": "Closed",
      "Id": 4
    },
    "ReasonClosed": {
      "Name": "Unassigned"
    },
    "Summary": "Granular events (OnWriteBlock), bytes read vs bytes written",
    "Type": {
      "Name": "Issue",
      "Id": 3
    },
    "VoteCount": 1,
    "Id": 6648
  },
  "FileAttachments": [],
  "Comments": [
    {
      "Message": "The progress event data for ZipProgressEventType.Saving_EntryBytesWritten is goofy -it mixes \"bytes written\" with \"total bytes to read\".\r\n\r\nFixing this requires a change in the interface - the event name should no longer be ZipProgressEventType.Saving_EntryBytesWritten.   It should be ZipProgressEventType.Saving_EntryBytesRead. I also need to change the doc to reflect this change. ",
      "PostedDate": "2008-11-25T08:58:37.36-08:00",
      "Id": -2147483648
    },
    {
      "Message": "",
      "PostedDate": "2008-11-25T08:59:20.467-08:00",
      "Id": -2147483648
    },
    {
      "Message": "",
      "PostedDate": "2013-02-21T18:44:35.253-08:00",
      "Id": -2147483648
    },
    {
      "Message": "",
      "PostedDate": "2013-05-16T05:32:34.53-07:00",
      "Id": -2147483648
    }
  ]
}