Add ZipArchiveEntry.Open(FileAccess) overload

[iremyux]

When a ZipArchive is opened in ZipArchiveMode.Update, calling ZipArchiveEntry.Open() always returns a read-write stream by invoking OpenInUpdateMode(). This causes the entire entry to be decompressed into memory, even when the caller only intends to read the entry's contents.
This PR adds a new Open(FileAccess access) overload to ZipArchiveEntry that allows callers to explicitly specify the desired access mode:

FileAccess.Read: Opens the entry in read mode OpenInReadMode, avoiding the memory overhead of decompression into a MemoryStream. This is useful when you only need to read the entry's contents in Update mode.
FileAccess.Write: Opens the entry in write mode OpenInWriteMode.
FileAccess.ReadWrite: Opens the entry in update mode OpenInUpdateMode, matching the current parameterless Open() behavior.

The method validates that the requested access is compatible with the archive's mode:

In Read mode: Only FileAccess.Read is allowed
In Create mode: Only FileAccess.Write or FileAccess.ReadWrite is allowed
In Update mode: All access modes are allowed. FileAccess.Read returns a read-only stream, while FileAccess.Write and FileAccess.ReadWrite both return a read-write-seekable stream. (FileAccess.Write and FileAccess.ReadWrite behave identically)

Fixes #101243

[dotnet-policy-service]

Tagging subscribers to this area: @dotnet/area-system-io-compression
See info in area-owners.md if you want to be subscribed.

[Copilot]

Pull request overview

This PR adds a new Open(FileAccess access) overload to ZipArchiveEntry that allows callers to explicitly specify the desired file access mode when opening an entry. This is particularly valuable in ZipArchiveMode.Update, where the existing parameterless Open() always returns a read-write stream by decompressing the entire entry into memory. The new overload allows specifying FileAccess.Read to avoid this memory overhead when only reading is needed.

Key Changes:

• New Open(FileAccess access) method validates that the requested access is compatible with the archive's mode and calls the appropriate internal open method (OpenInReadMode, OpenInWriteMode, or OpenInUpdateMode)
• Three new error message resources for incompatible access modes
• Comprehensive test coverage for all combinations of archive modes and access types

Reviewed changes

Copilot reviewed 4 out of 4 changed files in this pull request and generated 4 comments.

File	Description
src/libraries/System.IO.Compression/src/System/IO/Compression/ZipArchiveEntry.cs	Implements the new Open(FileAccess access) overload with validation logic for different archive modes
src/libraries/System.IO.Compression/ref/System.IO.Compression.cs	Adds the new public API surface to the reference assembly
src/libraries/System.IO.Compression/src/Resources/Strings.resx	Adds three new error message resources for invalid access scenarios
src/libraries/System.IO.Compression/tests/ZipArchive/zip_InvalidParametersAndStrangeFiles.cs	Adds 11 new test methods covering all valid and invalid access combinations for each archive mode

[Copilot]

Pull request overview

Copilot reviewed 4 out of 4 changed files in this pull request and generated 1 comment.

[Copilot]

Pull request overview

Copilot reviewed 4 out of 4 changed files in this pull request and generated 3 comments.

Comments suppressed due to low confidence (1)

src/libraries/System.IO.Compression/tests/ZipArchive/zip_InvalidParametersAndStrangeFiles.cs:2256

• The comment states that ReadWrite "opens in write mode" but based on the implementation (line 392 in ZipArchiveEntry.cs), it actually calls OpenInWriteMode() which may return a stream with different capabilities than implied. The comment should clarify what capabilities the returned stream actually has. Consider: "// ReadWrite is allowed in Create mode and calls OpenInWriteMode()"

            // ReadWrite should be allowed in Create mode (it opens in write mode)

[Copilot]

The <param> description should be a noun phrase that begins with an introductory article, per the documentation guidelines. Consider: "The file access mode for the returned stream."

[Copilot]

The <returns> description should be a noun phrase that begins with an introductory article. Consider: "A stream that represents the contents of the entry with the specified access capabilities."

Suggested change

	/// <returns>A Stream that represents the contents of the entry with the specified access capabilities.</returns>
	/// <returns>A <see cref="Stream"/> that represents the contents of the entry with the specified access capabilities.</returns>

[Copilot]

In Create mode with FileAccess.ReadWrite, the test verifies stream.CanWrite but doesn't verify stream.CanRead like the corresponding Update mode test does (line 2324-2326). For consistency and completeness, consider adding an assertion for stream.CanRead to match the behavior documented in the comment on line 2256.