New Post: Writing files to a Zip using AddEntry/SaveTo: Streams are closed late.

Mounting the horse from the rear: I built a fork of 10.1.3 with a ZipArchive.cs SaveTo reading as follows:

    protected override void SaveTo(Stream stream, CompressionInfo compressionInfo,
                                   IEnumerable<ZipArchiveEntry> oldEntries,
                                   IEnumerable<ZipArchiveEntry> newEntries)
    {
        using (var writer = new ZipWriter(stream, compressionInfo, string.Empty))
        {
            foreach (var entry in oldEntries.Concat(newEntries)
                                            .Where(x => !x.IsDirectory))
            {
                using (var entryStream = entry.OpenEntryStream())
                {
                    writer.Write(entry.FilePath, entryStream, entry.LastModifiedTime, string.Empty);
                }
                entry.Close();
            }
        }
    }

Only change is the entry.Close() call.

Use case: Move images to a cbz (http://en.wikipedia.org/wiki/Comic_Book_Archive_file). With your build, one must call GC.Collect() after saving the archive but before recycling the freshly archived originals, my fork doesn't need it.

Personally, I don't like the notion at all that some code allocates a resource and does not also implement a predictable path to the release of said resource. AbstractWritableArchive.cs line 106 has such an fileInfo.OpenRead() where no corresponding closure is to be seen in the vicinity... Though I couldn't really suggest something constructive.

This architecture also means all entry source streams are opened and held at the same time, requiring more resources than strictly necessary (see also http://blogs.technet.com/b/markrussinovich/archive/2009/09/29/3283844.aspx), and possibly limiting the number of files that can be added to an archive prematurely (think old C CRT: 2048 maximum).

(Yes, I know the Writer API probably will not suffer from these effects)