Open
Description
Expected behavior
I could not find any related topics, except an unanswered issue "CopyToAsync fails with ZipOutputStream #167".
One of c#'s greatest features over other languages is the async/await pattern. The .net streams all support async/await since ver 4.5 and there could be major implications and performance enhancers for FileStream in particular. Is there any plan to implement this support in this library?
Activity
Numpsy commentedon Apr 5, 2020
So, I had a little bit of a look at this (partly as it's requested, partly out of thinking it might be interesting to tinker with). I initially wondered if it would be possible to start at the bottom of the stream and add it a bit at a time, but the way the zip/gzip streams are imple,ented as subclasses of the deflator streams rather than as containers causes issues with that (if you only implement the async methds of the base class, async calls on the subclasses go through to those and miss the archive specific pieces).
So, bit more of an all-in change there.
However, as a starter - I adapted a few on the unit tests to use async stream calls as a test, and those changes could be made independantly of library changes (as it stands and async calls will be forwarded to the sync versions by the base stream class, but it async methods were to be implemented later that would mean there was already a test base for them).
@piksel and comments and/or objections to the idea of adding some async tests to the existing zip test suite? (would just be variants of the existing tests but with async stream calls to start with)
piksel commentedon Apr 7, 2020
No, I guess that would be fine.
Add async support on ZipOutputStream
mark-at-tusksoft commentedon May 6, 2021
Running into the same issue as reported in a similar library
haf/DotNetZip.Semverd#60
7 remaining items