{
  "WorkItem": {
    "AffectedComponent": {
      "Name": "",
      "DisplayName": ""
    },
    "ClosedComment": "",
    "ClosedDate": null,
    "CommentCount": 0,
    "Custom": null,
    "Description": "from http://dotnetzip.codeplex.com/discussions/264762\n \nI looked into adding files to an already existing spanned zip.\n \nFor example\n \n            foreach (var pdf in pdfFiles)\n            {\n                using (var outputZip = new ZipFile(@\"c:\\temp\\span.zip\"))\n                {\n                    outputZip.MaxOutputSegmentSize = 1417123;\n                    outputZip.AddFile(pdf);\n                    outputZip.Save();\n                }\n            }\n \n \nWhen I call Save() the second time through the loop there is already an span.z01 but an exception is raised in\n \nIonic.Zip.ZipSegmentedStream._SetWriteStream(UInt32 increment) in c:\\DotNetZip\\Zip Partial DLL\\ZipSegmentedStream.cs:line 317\n \n...because its trying to delete span.z01 and it appears to have the file open.\n \n------\n \nI think the optimal behavior here is to fail fast, when saving to a spanned archive and one of the segments already exists. When saving a segmented archive, there's no telling how many segments will be produced; the user has to just examine the segment files (Filename.zNN) to determine which segments were needed. \n \nNow suppose there is a spanned zip that uses 10 segments.  The app then reads the zip (ZipFile.Read()), removes a few entries, and adds a few.  It sets MaxOutputSegmentSize, then calls Save() again.  Now, how will the app or user determine whether the segments that have been produced in the fileysstem belong to the current save, or the prior set of segments? Obviously this can be a source of a great deal of confusion. \n \nThere are two possible solutions: \n \n1. \nDotNetZip could remove all the .zNN files, that are not part of the \"current save\", before beginning the save.  This approach would result in a loss of data, if a failure occurs during the save.   \n \n2. DotNetZip could prevent a save of a segmented archive using the same name as an existing (previously-saved) segmented zip. The library would detect this in the call to .Save(), by checking for the existence of a Filename.z01 file, before actually making any writes to the filesystem. \n \nAnyone with input, please respond here.  I'm leaning toward #2, because it holds a smaller potential for silently destroying data.\n \nIn order to help with #2, I could imagine exposing a static helper method to remove segmented files.  A call like ZipFile.RemoveSegments(\"Update.zip\"), would remove all files Update.z01, Update.z02... Update.z99, and Update.zip.    The app would need to make this call explicitly, before calling Save() to update a segmented zip.",
    "LastUpdatedDate": "2013-02-21T18:43:09.6-08:00",
    "PlannedForRelease": "",
    "ReleaseVisibleToPublic": false,
    "Priority": {
      "Name": "Low",
      "Severity": 50,
      "Id": 1
    },
    "ProjectName": "DotNetZip",
    "ReportedDate": "2011-07-13T16:47:35.94-07:00",
    "Status": {
      "Name": "Proposed",
      "Id": 1
    },
    "ReasonClosed": {
      "Name": "Unassigned"
    },
    "Summary": "Gracefully handle saving a spanned archive when a segment file already exists",
    "Type": {
      "Name": "Issue",
      "Id": 3
    },
    "VoteCount": 1,
    "Id": 13918
  },
  "FileAttachments": [],
  "Comments": []
}