Fix Zip64ExtraField handling

[edwardneal]

Bugfix for the outer loop tests which failed after PR #103153.

The original Zip64ExtraField.WriteBlock method contained logic to conditionally write the compressed size, uncompressed size, local header offset and starting disk number to the output stream. When this was modified to use BinaryPrimitives, (link) this condition wasn't ported across properly - it conditionally wrote into the destination buffer, but used constant field offsets. There was also one error in ZipArchiveEntry.WriteDataDescriptor - that's now corrected.

I don't see this pattern repeated anywhere else in ZipBlocks or ZipArchiveEntry. ZipArchiveEntry does sometimes write a ZIP64 data descriptor (link) but this logic is reasonable.

Outer loop tests which failed as a result of this bug:

• System.IO.Compression.Tests.zip_LargeFiles.CheckZIP64VersionIsSet_ForSmallFilesAfterBigFiles
• System.IO.Compression.Tests.zip_LargeFiles.UnzipOver4GBZipFile
• System.IO.Packaging.Tests.LargeFilesTests.CheckZIP64VersionIsSet_ForSmallFilesAfterBigFiles
  These were the only tests which failed because they're the only ones which generated large enough files to trigger the logic which wrote Zip64ExtraField. They're now passing locally.

Apologies again for missing this.

@carlossanlop - if you're happy with the diff, could you run the outer loop tests against this PR again please?

[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.

[carlossanlop]

/azp list

[azure-pipelines]

CI/CD Pipelines for this repository:

• runtime-coreclr outerloop
• runtime-coreclr jitstress
• runtime-coreclr jitstressregs
• runtime-coreclr jitstress2-jitstressregs
• runtime-coreclr gcstress0x3-gcstress0xc
• runtime-coreclr gcstress-extra
• runtime-coreclr r2r-extra
• runtime-coreclr jitstress-isas-x86
• runtime-coreclr jitstress-isas-arm
• runtime-coreclr jitstressregs-x86
• runtime-coreclr libraries-jitstressregs
• runtime-coreclr libraries-jitstress2-jitstressregs
• runtime-coreclr r2r
• runtime-coreclr runincontext
• runtime-coreclr crossgen2
• runtime-libraries-coreclr outerloop
• runtime-libraries-coreclr outerloop-windows
• runtime-libraries-coreclr outerloop-linux
• runtime-libraries-coreclr outerloop-osx
• runtime
• runtime-libraries enterprise-linux
• runtime-libraries stress-http
• runtime-libraries stress-ssl
• runtime-dev-innerloop
• runtime-coreclr crossgen2 outerloop
• coreclr-release-outerloop-nightly
• runtime-coreclr crossgen2-composite
• runtime-jit-experimental
• runtime-coreclr libraries-jitstress
• dotnet-linker-tests
• runtime-coreclr ilasm
• runtime-coreclr crossgen2-composite gcstress
• runtime-staging
• runtime-coreclr pgo
• runtime-coreclr libraries-pgo
• Antigen
• runtime-community
• Fuzzlyn
• runtime-coreclr superpmi-replay
• runtime-wasm
• runtime-coreclr superpmi-diffs
• runtime-coreclr superpmi-asmdiffs-checked-release
• runtime-extra-platforms
• jit-cfg
• runtime-wasm-perf
• runtime-llvm
• runtime-coreclr jitstress-random
• runtime-coreclr libraries-jitstress-random
• runtime-android-grpc-client-tests
• runtime-wasm-non-libtests
• runtime-android
• runtime-androidemulator
• runtime-ioslike
• runtime-ioslikesimulator
• runtime-linuxbionic
• runtime-maccatalyst
• runtime-coreclr pgostress
• runtime-coreclr jitstress-isas-avx512
• runtime-libraries-mono outerloop
• runtime-sanitized
• runtime-wasm-dbgtests
• runtime-wasm-optional
• runtime-nativeaot-outerloop
• runtime-coreclr jitstress-isas-sve
• runtime-coreclr superpmi-collect-test

[carlossanlop]

/azp run runtime-libraries-coreclr outerloop

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[carlossanlop]

Thanks for the quick fix submission. LGTM. Let's see what outerloop says.

[carlossanlop]

• These were the only tests which failed because they're the only ones which generated large enough files to trigger the logic which wrote Zip64ExtraField. They're now passing locally.

Just double checking: The outerloop tests get skipped by default AFAIK even when you run them locally, unless you pass the necessary msbuild global property in the command (if from CLI). Did you do this by any chance?

I think such suppression does not happen if you run the unit test from VS or VS Code instead. You can choose the specific test and it gets executed.

[edwardneal]

The VS test runner skips outerloop tests, even if I specifically select them. Those tests remain in the "not executed" state, but when that state rolls up to the parent, it looks like the entire suite passed...

It's an odd problem, but I've brute-forced it for the moment - I just locally commented out the OuterLoop attributes and ran the entire test suite for System.IO.Compression and System.IO.Packaging, specifically confirming that the previously-failing tests pass.

[carlossanlop]

Thanks for checking! So far the results don't show compression-related failures. I'm monitoring the remaining ones too.

[carlossanlop]

• runtime (Build browser-wasm linux Release LibraryTests) was cancelled already, but showing up as stuck.
• I opened issues for all the unrelated outerloop failures. Didn't find any Zip related errors.

Merging now!