{
  "WorkItem": {
    "AffectedComponent": {
      "Name": "",
      "DisplayName": ""
    },
    "ClosedComment": "",
    "ClosedDate": null,
    "CommentCount": 0,
    "Custom": null,
    "Description": "I have created a set of zip files using dotnetzip library using the following\n \nusing (ZipFile zip = new ZipFile())\n{\n   if (chkEncryption.Checked)\n   {\n      zip.Encryption = EncryptionAlgorithm.WinZipAes256;\n      zip.Password = textPassword.Text;\n   }\n   zip.AddDirectory(DirectoryToZip);\n   zip.Comment = \"Archive\";\n   zip.MaxOutputSegmentSize = 2 * 1024 * 1024; //2MB\n   zip.UseZip64WhenSaving = Zip64Option.Default;\n   zip.Save(ZipFileToCreate);\n}\n \nIt creates the zip files without any errors. I then try to extract all files from the zip file and get the following error while extracting.\n \n\"Bad MAC address\"\n \nI am extracting using the following code:\n \nfile.Extract(textExtractLoc.Text, ExtractExistingFileAction.OverwriteSilently);\n \nI am using version 1.9.1.8. This issue can be recreated with the tool provided along with DotNetZip.\n \nThe exception says\n \n[Ionic.Zip.BadStateException] = {Ionic.Zip.BadStateException: The MAC does not match.\n   at Ionic.Zip.WinZipAesCrypto.ReadAndVerifyMac(Stream s)\n   at Ionic.Zip.ZipEntry.VerifyCrcAfterExtract(Int32 actualCrc32)\n   at Ionic.Zip.ZipEntry.InternalExtract(String baseDir, Stream outstream, ...\n \nThe error occurs only when encryption is turned on along with splitting zip files. As a test i am splitting 2MB zip file size however i have tried with 2GB zip file sizes as well. There is an issue with MaxOutputSegmentSize as well where it accepts only an int value and can go upto 2 GB. It would be nice if it could support more.",
    "LastUpdatedDate": "2013-02-21T18:42:46.62-08:00",
    "PlannedForRelease": "",
    "ReleaseVisibleToPublic": false,
    "Priority": {
      "Name": "Low",
      "Severity": 50,
      "Id": 1
    },
    "ProjectName": "DotNetZip",
    "ReportedDate": "2012-08-28T08:17:48.7-07:00",
    "Status": {
      "Name": "Proposed",
      "Id": 1
    },
    "ReasonClosed": {
      "Name": "Unassigned"
    },
    "Summary": "Extract Issue with Split zip + AES Enc",
    "Type": {
      "Name": "Issue",
      "Id": 3
    },
    "VoteCount": 1,
    "Id": 15557
  },
  "FileAttachments": [],
  "Comments": [
    {
      "Message": "I'm seeing this exact same issue with 1.9.1.8",
      "PostedDate": "2012-09-05T09:57:23.25-07:00",
      "Id": -2147483648
    },
    {
      "Message": "I'm seeing this exact same issue with 1.9.1.8",
      "PostedDate": "2013-01-09T08:33:43.487-08:00",
      "Id": -2147483648
    },
    {
      "Message": "Occurs exactly the same problem with me.",
      "PostedDate": "2013-01-09T09:01:32.71-08:00",
      "Id": -2147483648
    },
    {
      "Message": "Same problem here with 1.9.1.8 - \"The MAC does not match\"\r\n\r\n\r\n\r\nI need a fix for this, otherwise this DotNETZip Library is completely unusable for me. I need to programmatically split large data files.\r\n\r\n \r\n\r\nIs there a way for me to get my hands on the source code, debug it and fix it for everyone? I'm new to the whole CodePlex / open source thing... but I do have 20 years MS software development experience and am sure I could fix it in a flash... Any pointers would be appreciated. I don't want to spend weeks on this as I have a job. But if I can get involved in an evening or 2 of my spare time... then I'd be interested.",
      "PostedDate": "2013-01-16T06:28:44.05-08:00",
      "Id": -2147483648
    },
    {
      "Message": "I had the same problem. Once I downloaded the source, downloaded WiX, Silverlight developer stuff!! and got it running, it took me a little while to step through the code. But I got there in the end...\r\n\r\n\r\n\r\nBasically on line 946 of ZipEntry.Extract.cs (in the ZipDLL project), in a method named VerifyCrcAfterExtract, there is a call to WinZipAesCipherStream.ReadAndVerifyMac\r\n\r\n\r\n\r\nThe ReadAndVerifyMac method assumes the Zip file stream we have been reading from is positioned at the end of the encrypted data for the last file that has been read out (and decrypted and inflated most probably). That is where the MAC for the file that has just been decrypted is stored...\r\n\r\nIn my case, where I am only extracting one file from the Zip archive, the file stream was disposed of once the file data was readout. So the call below to ReadAndVerifyMac actually creates a whole new file stream that is positioned at the beginning of the file - and as you'd expect the call to ReadAndVerifyMac reads the completely wrong data from the file and fails.\r\n\r\nWinZipAesCipherStream wzs = _inputDecryptorStream as WinZipAesCipherStream;\r\n\r\n_aesCrypto_forExtract.CalculatedMac = wzs.FinalAuthentication;\n_aesCrypto_forExtract.ReadAndVerifyMac(this.ArchiveStream); // throws if MAC is bad\r\n\r\nThe call above to this.ArchiveStream recreates the file stream from scratch, as it has already been disposed of.\r\n\r\nA quick and dirty work around is to seek to the correct position in the file by executing the following line of code before the call to ReadAndVerifyMac -\r\n\r\nthis.ArchiveStream.Position = __FileDataPosition + _CompressedFileDataSize;\r\n\r\nbut a much better solution, avoiding the need to open a new file stream, is to read out and store the MAC from the file after the last encrypted/compressed data is read, but before the file stream is disposed of. For me that would be done in a method called\r\n\r\nprivate Int32 ExtractOne(Stream output)\r\n\r\nin the file ZipEntry.Extract.cs, just before the end of the try block at line 1073.................\r\n\r\n\r\n\r\nAnyway, I have my fix and only have to worry about my own bugs now!",
      "PostedDate": "2013-01-16T17:30:57.123-08:00",
      "Id": -2147483648
    },
    {
      "Message": "",
      "PostedDate": "2013-02-21T18:42:46.62-08:00",
      "Id": -2147483648
    }
  ]
}