{
  "WorkItem": {
    "AffectedComponent": {
      "Name": "",
      "DisplayName": ""
    },
    "ClosedComment": "I believe this is fixed in changeset 79646.  First binary to contain this fix will be v1.9.1.6.  please let me know if this does not fix the problems you observed.",
    "ClosedDate": "2011-06-22T16:44:20.66-07:00",
    "CommentCount": 0,
    "Custom": null,
    "Description": "The field \"total number of disks\" which is part of the Zip64 end of central directory locator is off by one in files created by Ionic Zip. E.g. if the archive consist of only one part (disk) the number will be '0' (expected '1'), if it consists of 556 parts the number will be 555.\n \nThis makes it impossible to use most Zip64-enabled Java zip libraries for unzipping files created by the Ionic Zip Library.",
    "LastUpdatedDate": "2013-05-16T05:31:44.017-07:00",
    "PlannedForRelease": "v1.9.1.8 DotNetZip - Latest Stable",
    "ReleaseVisibleToPublic": true,
    "Priority": {
      "Name": "Low",
      "Severity": 50,
      "Id": 1
    },
    "ProjectName": "DotNetZip",
    "ReportedDate": "2010-09-15T02:52:54.02-07:00",
    "Status": {
      "Name": "Closed",
      "Id": 4
    },
    "ReasonClosed": {
      "Name": "Unassigned"
    },
    "Summary": "Total number of disks is off by one - InfoZip complains",
    "Type": {
      "Name": "Issue",
      "Id": 3
    },
    "VoteCount": 2,
    "Id": 11936
  },
  "FileAttachments": [
    {
      "FileId": 3492,
      "FileName": "DotNetZip1.9.1.5CreatedZip64ArchiveThatErrorsWithInfoZip.zip",
      "DownloadUrl": ".\\3492"
    }
  ],
  "Comments": [
    {
      "Message": "The Info-Zip tools also have problems with DotNetZip 1.9.1.5-created archives if Zip64 extensions are used (sample file attached). I managed to narrow this down to field \"total number of disks\" in \"Zip64 end of central directory locator\". Field's value is \"0\", I understand it should be \"1\". If I set it to \"1\" the Info-Zip errors vanish.\r\n\r\nOutput from Info-Zip's Zip 3.0 (July 5th 2008) - it seems to expect other split archive:\r\nc:\\>zip -T DotNetZip1.9.1.5CreatedZip64ArchiveThatErrorsWithInfoZip.zip\r\n\r\n\r\nCould not find:\r\n  DotNetZip1.9.1.5CreatedZip64ArchiveThatErrorsWithInfoZip.z01\r\n\r\nHit c      (change path to where this split file is)\r\n    q      (abort archive - quit)\r\n or ENTER  (try reading this split again):\r\n\r\nOutput from Info-Zip's UnZip 6.00 (20 April 2009):\r\nc:\\>unzip -Z DotNetZip1.9.1.5CreatedZip64ArchiveThatErrorsWithInfoZip.zip\r\nArchive:  DotNetZip1.9.1.5CreatedZip64ArchiveThatErrorsWithInfoZip.zip\r\nZip file size: 314 bytes, number of entries: 65535\r\nwarning [DotNetZip1.9.1.5CreatedZip64ArchiveThatErrorsWithInfoZip.zip]:  76 extra bytes at beginning or within zipfile\r\n  (attempting to process anyway)\r\nerror [DotNetZip1.9.1.5CreatedZip64ArchiveThatErrorsWithInfoZip.zip]:  reported length of central directory is\r\n  -76 bytes too long (Atari STZip zipfile?  J.H.Holm ZIPSPLIT 1.1\r\n  zipfile?).  Compensating...\r\n-rw----     4.5 fat        0 bx stor 10-Sep-25 21:08 updates/\r\nerror:  expected central file header signature not found (file #2).\r\n  (please check that you have transferred or created the zipfile in the\r\n  appropriate BINARY mode and that you have compiled UnZip properly)",
      "PostedDate": "2010-09-27T05:34:22.447-07:00",
      "Id": -2147483648
    },
    {
      "Message": "",
      "PostedDate": "2010-09-27T05:36:08.837-07:00",
      "Id": -2147483648
    },
    {
      "Message": "",
      "PostedDate": "2010-09-27T09:40:18.343-07:00",
      "Id": -2147483648
    },
    {
      "Message": "Looking at the source code (ZipFile.Save.cs) the value actual seems to be set to \"numSegments-1\", removing that \"-1\" should probably solve the issue, right?",
      "PostedDate": "2010-09-27T09:57:32.643-07:00",
      "Id": -2147483648
    },
    {
      "Message": "",
      "PostedDate": "2011-06-17T20:33:42.91-07:00",
      "Id": -2147483648
    },
    {
      "Message": "Ok, I think I understand the bug report and the suggested solution.  One detail though: It is my understanding that while the zip.exe tool supports multi-party archives (aka spanned archives, split archives), the unzip tool does not.  Is this correct?  \r\n\r\nhere's the warning message I got with unzip.exe: \r\n\r\nwarning [256k/256k.zip]:  zipfile claims to be last disk of a multi-part archive;  attempting to process anyway, assuming all parts have been concatenated  together in order.  Expect \"errors\" and warnings...true multi-part support  doesn't exist yet (coming soon).\r\nfile #1:  bad zipfile offset (local header sig):  4\r\nfile #2:  bad zipfile offset (lseek):  172032\r\netc....\r\n\r\nSo, ... I can change the code in ZipFile.Save.cs, but still, infozip's unzip.exe is not working for segmented archives.   It appears that infozip unzip does not support them. \r\n\r\nThe infozip zip.exe tool DOES support spanned archives.  so I can test the case where infozip creates the segmented archive, and dotnetzip reads/extracts.  But I cannot test the converse - DNZ creating the segmented archive, and infozip unzip.exe reading/extracting. \r\n\r\nIs this consistent with your understanding?  It's odd to me that infozip works with zip64 in creation but not in reading. \r\n\r\n",
      "PostedDate": "2011-06-22T03:01:06.59-07:00",
      "Id": -2147483648
    },
    {
      "Message": "",
      "PostedDate": "2011-06-22T16:44:20.66-07:00",
      "Id": -2147483648
    },
    {
      "Message": "",
      "PostedDate": "2013-02-21T18:43:26.447-08:00",
      "Id": -2147483648
    },
    {
      "Message": "",
      "PostedDate": "2013-05-16T05:31:44.017-07:00",
      "Id": -2147483648
    }
  ]
}