ZipArchive in Update mode rewriting when no changes made

[akindle]

Description

I'd rather post this as a comment on the related PR or related issue, but both are already closed. We've recently completed and shipped a migration from .NET Framework 4.8 to .NET 10, but this behavioral regression is now showing up in bug reports from customers. Our application's underlying file type is built upon System.IO.Packaging, and this bug is causing unnecessary rewrites and I/O just closing unmodified files.

Is there any chance of this fix shipping in a .NET 10 point release, or are we stuck waiting until the fall for .NET 11?

Reproduction Steps

See #123719

Expected behavior

See #123719

Actual behavior

See #123719

Regression?

Yes

Known Workarounds

Downgrade to .NET 8
Upgrade to .NET 11 preview

For us, neither of these are actually viable workarounds - retargeting down to .NET 8 will hit dependency problems, and we can't ship on a preview build of .NET.

Configuration

No response

Other information

No response

[dotnet-policy-service]

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

[MihuBot]

I'm a bot. Here are possible related and/or duplicate issues (I may be wrong):

• Bug? - ZipArchive modifies underlying stream even if no archive changes made #34506
• System.IO.Compression: ZipArchiveEntry always stores uncompressed data in memory #1544

[akindle]

I think this should probably be area-System.IO.Compression / cc @karelz

[dotnet-policy-service]

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

[alinpahontu2912]

Hey @akindle, in order for us to consider backporting, we need a great business justification for it. Could you please provide some more in-depth information about how your business is affected ?