{
  "WorkItem": {
    "AffectedComponent": {
      "Name": "",
      "DisplayName": ""
    },
    "ClosedComment": "",
    "ClosedDate": null,
    "CommentCount": 0,
    "Custom": null,
    "Description": "I'm thinking about Append semantics.  Currently, if an application opens a large zip file, then adds 3 small entries, the entire zip file content is copied, then the 3 new entries are added.  This is inefficient in terms of time and space, and unnecessarily so.   It would be nice if it were possible to just append new zip content to the existing zip file, and then fixup the central directory as appropriate. \n \nInitially I was imagining a new set of static methods on the ZipFile class.  There would be various overloads:\n \nvoid ZipFile.AppendFile(String zipFileName, String nameOfFilesystemFileToAppend);\nvoid ZipFile.AppendFile(Stream seekableStream, String nameOfFilesystemFileToAppend);\nvoid ZipFile.AppendEntry(String zipFileName, WriteDelegate d);\n \n...and so on. \n \nBut this is pretty limited. You could only append a single entry.  If you wanted to append 2 entries, you'd have to read and scan the zip file twice.  Not so nice. \n \nThen I thought maybe there should be a way to open a zip file for append only.  a new method, ZipFile.OpenForAppend().  This mode would allow AddEntry/AddFile operations, but nothing else.  If an existing ZipEntry were modified in any way, it would throw an error .    Any call to RemoveEntry would throw.   AddEntry would work just as it does now.  Calling Save() on a ZipFile opened for append would be faster, with less copying of data, less moving of bytes around.  Any call to Save(stream) would save the zip content to a new stream. \n \nIt might be possible to make the append semantics implicit or transparent, where feasible. In other words, if you open an existing ZipFile as normal, then only add entries, you could get apend semantics. I don't think I like this idea, because it's a bit of a surprise.  I think I'd rather be explicit about opening a zip file for append semantics. \n \n----\n \nThere's an added complication when doing \"append\" on segmented zip files. The library would have to do the right thing in that case as well. \n \n----\n \nInterested in feedback.\n \nThis needs more thought.",
    "LastUpdatedDate": "2013-08-02T18:07:14.613-07:00",
    "PlannedForRelease": "",
    "ReleaseVisibleToPublic": false,
    "Priority": {
      "Name": "Low",
      "Severity": 50,
      "Id": 1
    },
    "ProjectName": "DotNetZip",
    "ReportedDate": "2010-01-20T23:40:55.183-08:00",
    "Status": {
      "Name": "Proposed",
      "Id": 1
    },
    "ReasonClosed": {
      "Name": "Unassigned"
    },
    "Summary": "Append semantics, for fast, efficient (though restricted) update of Zip files.",
    "Type": {
      "Name": "Issue",
      "Id": 3
    },
    "VoteCount": 6,
    "Id": 10034
  },
  "FileAttachments": [],
  "Comments": [
    {
      "Message": "It would be great using OpenForAppend() becouse on PocketPC Save() taking terrible long time...",
      "PostedDate": "2010-05-03T15:04:15.843-07:00",
      "Id": -2147483648
    },
    {
      "Message": "",
      "PostedDate": "2011-11-08T14:16:58.937-08:00",
      "Id": -2147483648
    },
    {
      "Message": "This is a feature that I would very much like to see. We have a zip file that is \"built\" incrementally. We add one or more files and then the file must be committed (to avoid data loss in case of a computer or program crash). Sometime later we need to add additional files (and maybe modify some small files), and commit the zip-file again. Since this zip-file can become very large, it would be very good if the full file was not copied on each Save.\r\n\r\nI took a quick look at the ZipFile.Save method and have a very non-initiated suggestion:\r\n\r\nWould it be possible to implement a new method, e.g. SaveIncremental, that performs the following:\r\n\r\nInitiate WriteStream to the the same stream as the ZipFile input Stream (requires the stream to be read/write)\r\nSeek to the end of WriteStream\r\nFor each ZipEntry, \r\n  If entry is new, just write it using the standard compression \r\n  If entry has changed, also write it using the standard compression and update the central directory with the new offset (orphaning the old entry)\r\n  If entry has not changed (according to the same criteria as CopyThroughWithNoChange), just keep the ZipEntry as it is in the input stream\r\n\r\nIf an entry has been removed, it will just not be included in the new central directory structure (leaving a hole in the file).\r\n\r\nThis way there's no need to open the ZipFile using a special mode (except that the input stream must be read/write).\r\n\r\nI have probably oversimplified things immensely (e.g. I have not considered segmented files), so this suggestion might not work. But it might be worth considering, and it would be very useful to us.\r\n\r\n",
      "PostedDate": "2011-11-08T14:42:58.38-08:00",
      "Id": -2147483648
    },
    {
      "Message": "",
      "PostedDate": "2012-09-04T00:48:24.16-07:00",
      "Id": -2147483648
    },
    {
      "Message": "",
      "PostedDate": "2013-02-21T18:43:42.17-08:00",
      "Id": -2147483648
    },
    {
      "Message": "",
      "PostedDate": "2013-08-02T18:07:14.613-07:00",
      "Id": -2147483648
    }
  ]
}