Add Flush to ZipArchive

[twsouthwick]

When creating a package on .NET Core, you have to call Dispose or Close to get the contents written out to the underlying stream. This works on .NET Framework, but fails on .NET Core:

[Fact]
public void FlushSavesPackageContents()
{
   var uri = new Uri("/something", UriKind.Relative);
   var contentType = "something/other";

   byte[] CreatePackage()
   {
       using (var ms = new MemoryStream())
       {
           using (var package = Package.Open(ms, FileMode.Create))
           {
               package.CreatePart(uri, contentType);

               Assert.Empty(ms.ToArray());

               package.Flush();

               // All data should be written after calling flush
               return ms.ToArray();
           }
       }
   }

   var bytes = CreatePackage();

   Assert.NotEmpty(bytes);

   using (var ms = new MemoryStream(bytes))
   using (var package = Package.Open(ms))
   {
       Assert.True(package.PartExists(uri));
       Assert.Equal(contentType, package.GetPart(uri).ContentType);
   }
}

[twsouthwick]

It appears that this is due to not flushing the underlying zip. In .NET Framework it is flushed, but not in .NET Core. I'll try adding that in and see if it works.

[twsouthwick]

@ianhays ZipArchive does not have a Flush method. Is there a way to flush the current archive state to a stream, or is this part of the issue to get streaming support for compression?

[ianhays]

I'm not sure why ZipArchive in netcore doesn't have a flush method. It was ported to CoreFX without one. It could be that it was removed since it was internal-only in netfx and not used in netcore.

We could probably add it as public, at least for ZipArchiveMode.Create. I'm not sure how that would affect being able to open some entries though. We would need to add lots of tests to first verify the netfx Flushing behavior - which may be tricky since it's not exposed through ZipArchive - then try to match that in core. At that point a streaming API may be the better solution.

[twsouthwick]

Yeah - I took a shot at just calling the WriteFile method (which is what the Dispose method calls) in lieu of a flush and it caused a lot of problems. It seems to close streams, so it expects to be called in the dispose. Exposing it would be nice, but I agree that there will be a need to add a bunch of tests for it.

We seem to be finding many issues with System.IO.Packaging in the DocumentFormat.OpenXml library that would be fixed with the streaming API...

[daniel-white]

Any progress on this? we use DocumentFormat.OpenXml and it has intentional bugs that keep parity between .net fx and .net core. see dotnet/Open-XML-SDK#380

[ianhays]

There hasn't been any progress that I'm aware of, no. I've updated the title and the tags with the current state of the issue and marked it as up-for-grabs.

The work item here is to plan an API addition of Flush to ZipArchive. To do that, a formal proposal will have to be made and the design questions in the comments above should be answered.

So I have just hit this issue too. Porting some code from FX to .Net. Need ZipPackage to be able to flush the stream. Is there any workaround ? Else, I can take on adding the API to ZipArchive.

[odhanson]

Sorry, replaced my github account. So the message above is from me.

I have made the changes to add a Flush API and added tests to verify. I will follow through the procedures for getting the API and change approved.

[SinxHe]

when will the flush function will be added?

[odhanson]

@SinxHe , unfortunately fixing this issue is a bit more tricky than I initially anticipated. As I have managed to work around this issue for now, I am not sure when I will be able to get back to work on a fix for this.

[twsouthwick]

@odhanson Thanks for taking a look at this. Can you share a fork with your current progress so someone else can build off of what you've tried?

[odhanson]

@twsouthwick

Sure. I have made a fork under my account:
https://github.com/odhanson/corefx/tree/dev/Flush

There are two commits, the first adds the API and some tests. The second implements the API, and adds some tests that failed my implementation :(. So the good news is, that we do have a bunch of tests to base off of.