System.IO.Compression.ZipFile.CreateFromDirectory: overloads to write to a stream rather than a file

[halgab]

Rationale and usage

The ZipFile.CreateFromDirectory signatures all assume that we want to write the resulting file directly to the file system. But for small archives that are directly uploaded to cloud storage, this is not very efficient.

Symmetrically, ZipFile.ExtractToDirectory overloads that take a zip stream rather than a file would be convenient to unzip cloud archives directly onto a drive.

Proposed API

Zipping

namespace System.IO.Compression;
public static class ZipFile
{
+   public static void CreateFromDirectory(string sourceDirectoryName, Stream destination)
+   public static void CreateFromDirectory(string sourceDirectoryName, Stream destination, CompressionLevel compressionLevel, bool includeBaseDirectory)
+   public static void CreateFromDirectory(string sourceDirectoryName, Stream destination, CompressionLevel compressionLevel, bool includeBaseDirectory, Encoding? entryNameEncoding)
    public static void CreateFromDirectory(string sourceDirectoryName, string destinationArchiveFileName)
    public static void CreateFromDirectory(string sourceDirectoryName, string destinationArchiveFileName, CompressionLevel compressionLevel, bool includeBaseDirectory)
    public static void CreateFromDirectory(string sourceDirectoryName, string destinationArchiveFileName, CompressionLevel compressionLevel, bool includeBaseDirectory, Encoding? entryNameEncoding)
}

Unzipping

namespace System.IO.Compression;
public static class ZipFile
{
+   public static void ExtractToDirectory(Stream source, string destinationDirectoryName) { }
+   public static void ExtractToDirectory(Stream source, string destinationDirectoryName, bool overwriteFiles) { }
+   public static void ExtractToDirectory(Stream source, string destinationDirectoryName, Encoding? entryNameEncoding) { }
+   public static void ExtractToDirectory(Stream source, string destinationDirectoryName, Encoding? entryNameEncoding, bool overwriteFiles) { }
    public static void ExtractToDirectory(string sourceArchiveFileName, string destinationDirectoryName) { }
    public static void ExtractToDirectory(string sourceArchiveFileName, string destinationDirectoryName, bool overwriteFiles) { }
    public static void ExtractToDirectory(string sourceArchiveFileName, string destinationDirectoryName, Encoding? entryNameEncoding) { }
    public static void ExtractToDirectory(string sourceArchiveFileName, string destinationDirectoryName, Encoding? entryNameEncoding, bool overwriteFiles)
}

There is a discussion below to also add overloads to ZipFile.Open that take a stream instead of a string, but there doesn't seem to be much value on adding those because the user can simply use new ZipArchive(Stream, ZipArchiveMode).

These APIs are analogous to the ones we already added in System.Formats.Tar.TarFile.

[wcontayon]

The overload will need to write a new signature on these functions Open and DoCreateFromDirectory of the System.IO.Compression.ZipFile

public static ZipArchive Open(Stream archiveStream, ZipArchiveMode mode, Encoding entryNameEncoding);
private static void DoCreateFromDirectory(string sourceDirectoryName, Stream destinationStram, CompressionLevel? compressionLevel, bool includeBaseDirectory, Encoding entryNameEncoding);

It'll be the same with a little bit of difference for ExtractToDirectory.

@wfurt , I could try a PR for this

[wfurt]

we need to get API approval first.
https://github.com/dotnet/corefx/blob/master/Documentation/coding-guidelines/adding-api-guidelines.md

cc: @carlossanlop

[halgab]

I've updated the issue to better stick to the guidelines. Please tell me if it's still lacking. Thanks for considering this!

[carlossanlop]

Thank you @halgab for making the changes.

Please tell me if it's still lacking

We have another page in our documentation that provides better details about the API proposal stage:
dotnet/corefx/blob/master/Documentation/project-docs/api-review-process.md#steps

Step 3 in particular states the following:

we want to make sure that the proposal is actionable, i.e. has a concrete design, a sketch of the APIs and some code samples that show how it should be used. If changes are necessary, the requester is encouraged to edit the issue description. This allows folks joining later to understand the most recent proposal. To avoid confusion, the requester should maintain a tiny change log, like a bolded "Updates:" followed by a bullet point list of the updates that were being made.

So can you please add the code usage examples and the change log? And if you feel like adding more details to the concrete design descriptions (Rationale and usage, Proposed API), feel free to do so. Let us know if you have any questions.

[carlossanlop]

Triage:
This looks like a legitimate scenario. We should polish the API design.
Potential alternative: add members to ZipArchive to create entries from directories and files.

[carlossanlop]

Related to this: https://github.com/dotnet/corefx/issues/13207

[LeaFrock]

Any progress on this issue? I've met a requirement similar to this. It's a web api which generates several files(with MemoryStream format), then zip them together, and finally response back to client side. Why not add a ZipStream similar to ZLibStream etc..?