{
  "WorkItem": {
    "AffectedComponent": {
      "Name": "",
      "DisplayName": ""
    },
    "ClosedComment": "CrcCalculatorStream.Seek() always throws - this is expected and correct behavior.  CanSeek() should have been returning false, in all cases.  It has now been changed to do so, via  workitem 12486.  This change is available in DotNetZip starting with v1.9.1.6.  ",
    "ClosedDate": "2011-06-13T14:34:27.077-07:00",
    "CommentCount": 0,
    "Custom": null,
    "Description": "Hi,\n \nFirst of all, thanks a lot for this great library!\n \nThe property CanSeek of class CrcCalculatorStream returns \"_innerStream.CanSeek\" but the method seek only contains a NotImplemented exception.\nIt would be great if the implementation of method CrcCalculatorStream.Seek could be changed to \"return _innerStream.Seek(...)\".\n \nIt would be helpful for me because I need the stream for further operations, which require seeking.\n \nThanks and best regards,\nStefan Jauch",
    "LastUpdatedDate": "2013-05-16T05:31:40.04-07:00",
    "PlannedForRelease": "",
    "ReleaseVisibleToPublic": false,
    "Priority": {
      "Name": "Low",
      "Severity": 50,
      "Id": 1
    },
    "ProjectName": "DotNetZip",
    "ReportedDate": "2010-12-16T02:42:35.147-08:00",
    "Status": {
      "Name": "Closed",
      "Id": 4
    },
    "ReasonClosed": {
      "Name": "Unassigned"
    },
    "Summary": "CrcCalculatorStream does not support seeking even if property CanSeek returns true",
    "Type": {
      "Name": "Issue",
      "Id": 3
    },
    "VoteCount": 1,
    "Id": 12699
  },
  "FileAttachments": [],
  "Comments": [
    {
      "Message": "Hi Stefan,\r\n\r\nI think the CrcCalculatorStream needs to be forward-only - if you moved backwards and modified the data it would invalidate the calculated crc32 value. It *should* be possible (but complicated) to write a seekable *read-only* CrcCalculatorStream, but the class would need to keep track of the crc for individual byte ranges it had already read so it could avoid applying them to the \"total\" crc twice. It would then have to use crc32_combine to merge the crc results of individual ranges when they are found to be contiguous, which would probably affect performance.\r\n\r\nThere are a coulpe of suggestions for workarounds at the bottom of this thread that might help...\r\n\r\nhttp://dotnetzip.codeplex.com/Thread/View.aspx?ThreadId=216432\r\n\r\nCheers,\r\n\r\nMike\r\n\r\n",
      "PostedDate": "2010-12-16T07:07:10.127-08:00",
      "Id": -2147483648
    },
    {
      "Message": "Related workitem: http://dotnetzip.codeplex.com/workitem/12486",
      "PostedDate": "2010-12-16T07:35:22.57-08:00",
      "Id": -2147483648
    },
    {
      "Message": "",
      "PostedDate": "2011-06-13T14:34:27.077-07:00",
      "Id": -2147483648
    },
    {
      "Message": "",
      "PostedDate": "2013-02-21T18:43:20.143-08:00",
      "Id": -2147483648
    },
    {
      "Message": "",
      "PostedDate": "2013-05-16T05:31:40.04-07:00",
      "Id": -2147483648
    }
  ]
}