{
  "WorkItem": {
    "AffectedComponent": {
      "Name": "",
      "DisplayName": ""
    },
    "ClosedComment": "fixed in changeset 33771.  First binary to get this fix is v1.8.3.37. ",
    "ClosedDate": "2009-06-25T22:47:08.283-07:00",
    "CommentCount": 0,
    "Custom": null,
    "Description": "I've just been trying out the new 1.8.3.35 version with Zip64 files and I've found a problem.  I am also using AES encryption and I can't extract any of the Zip64 entries in my Zip file (with WinZip - it seems to work OK with DotNetZip).\n \nLooking at the code I think I can see what is happening.  For the local header you are now creating a Zip64 field of just 16 bytes (for the uncompressed size and compressed size).  However, in WriteFileData (around line 4201) where you have detected that Zip64 is needed you are attempting to write the uncompressed size, compressed size and relative offset to the Zip64 field.  But as you have only allocated 16 bytes in this field you are overwriting whatever comes next in the header - either the AES field or the NTFS times.\n \nOn a related note, in ProcessExtraField you always attempt to read the local offset from the Zip64 field.  In not sure what would happen if you are reading a local header where this value is not present rather than the central directory",
    "LastUpdatedDate": "2013-05-16T05:32:16.383-07:00",
    "PlannedForRelease": "",
    "ReleaseVisibleToPublic": false,
    "Priority": {
      "Name": "Low",
      "Severity": 50,
      "Id": 1
    },
    "ProjectName": "DotNetZip",
    "ReportedDate": "2009-06-25T18:04:21.987-07:00",
    "Status": {
      "Name": "Closed",
      "Id": 4
    },
    "ReasonClosed": {
      "Name": "Unassigned"
    },
    "Summary": "Error extracting >4GB file with WinZip",
    "Type": {
      "Name": "Issue",
      "Id": 3
    },
    "VoteCount": 1,
    "Id": 7941
  },
  "FileAttachments": [],
  "Comments": []
}