[System.IO.Compression] ZipArchive copies Stream to MemoryStream

[ThomasGoulet73]

I am extracting multiple multiple large zip files asynchronously using ZipArchive with the constructor ZipArchive(Stream, ZipArchiveMode.Read) and I get an OutOfMemoryException because the constructor copies my stream to a memory stream entirely and it does not seem to do anything with it (https://github.com/dotnet/corefx/blob/bc115700c3ece60acd6b8dbe4b0bdb8f6f80c756/src/System.IO.Compression/src/System/IO/Compression/ZipArchive.cs#L146). I think it is just replacing the stream parameter with a new memory stream, copies the old stream parameter to the new stream parameter and seek to beginning so that the calling method can reuse the stream.

Would it be possible to avoid copying the stream to a memory stream to reduce memory usage ?

It would also be nice to have asynchonous methods like ZipArchive.ExtractToDirectoryAsync and ZipArchiveEntry.ExtractToFileAsync with events in ZipArchive like ArchiveEntryExtracted for progress.

[stephentoub]

Would it be possible to avoid copying the stream to a memory stream to reduce memory usage ?

Can you use a seekable stream?

[ThomasGoulet73]

Would it be possible to avoid copying the stream to a memory stream to reduce memory usage ?

Can you use a seekable stream?

Wouldn't it still copy all the stream inside a new memory stream here ?

[ThomasGoulet73]

I didn't understand what you meant. Is your answer related to the check here ? That if it can seek, it does not create a new memory stream. But still, why does it forces the stream parameter to be seekable after the constructor ?

[ThomasGoulet73]

I'll just store my archive in a temporary file and extract the file.

[stephentoub]

Is your answer related to the check here ? That if it can seek, it does not create a new memory stream.

Right

why does it forces the stream parameter to be seekable after the constructor

The rest of the implementation needs to seek. If the incoming stream isn't seekable, it copies it to one that is and uses the seekable copy instead.

[carlossanlop]

@ThomasGoulet73 to avoid mixing issues, can you please open a new issue to address this request separately?:

It would also be nice to have asynchonous methods like ZipArchive.ExtractToDirectoryAsync and ZipArchiveEntry.ExtractToFileAsync with events in ZipArchive like ArchiveEntryExtracted for progress.

[stephentoub]

There's already an issue for that:
#1541

Given that's covered and the question here has been addressed, I think we can close this.

Thanks.