Fix Zip64 archive central directory extraction in ZipReader - #30685
Open
meteorcloudy wants to merge 1 commit into
Open
Fix Zip64 archive central directory extraction in ZipReader#30685meteorcloudy wants to merge 1 commit into
meteorcloudy wants to merge 1 commit into
Conversation
In commit b12c06a, ZipReader.readCentralDirectory() was modified to compute the central directory offset as actualCenEnd - zipData.getCentralDirectorySize(), replacing the parsed zipData.getCentralDirectoryOffset(). This broke reading standard Zip64 archives where 32-bit EOCD fields do not overflow (as the 76-byte Zip64 EOCD and locator sit between the central directory and the 32-bit EOCD, shifting the computed offset 76 bytes into the central directory) or when centralDirectorySize is 0xFFFFFFFF. This change restores ZipReader's standard central directory parsing to use zipData.getCentralDirectoryOffset(), populates centralDirectorySize in Zip64EndOfCentralDirectory.read(), and restricts the unadjusted SFX calculation strictly to AdjustSfx. Fixes bazelbuild#30681.
github-actions
Bot
added
team-Rules-Java
There was a problem hiding this comment.
Pull request overview
Fixes a regression in ZipReader central directory parsing for Zip64 archives introduced by #30530 / issue #30681, restoring correct central directory start handling while isolating SFX-specific offset heuristics to AdjustSfx.
Changes:
- Reverts Zip64 central directory start computation to use the parsed central directory offset (and narrows “end-minus-size” computation to SFX adjustment only).
- Populates
centralDirectorySizefrom the Zip64 EOCD record to support correct size-based computations. - Adds a regression test for Zip64 archives that include Zip64 EOCD/locator while still having valid 32-bit EOCD offsets; updates SFX-related test and tool usage to use the new AdjustSfx-specific reader construction.
Reviewed changes
Copilot reviewed 4 out of 4 changed files in this pull request and generated 1 comment.
| File | Description |
|---|---|
| src/java_tools/singlejar/javatests/com/google/devtools/build/zip/ZipReaderTest.java | Adds a Zip64 regression test and updates SFX test to use the AdjustSfx-specific ZipReader creation path. |
| src/java_tools/singlejar/java/com/google/devtools/build/zip/ZipReader.java | Restores standard central directory parsing behavior and introduces an AdjustSfx-only parsing mode. |
| src/java_tools/singlejar/java/com/google/devtools/build/zip/Zip64EndOfCentralDirectory.java | Ensures Zip64 EOCD parsing populates central directory size. |
| src/java_tools/singlejar/java/com/google/devtools/build/zip/AdjustSfx.java | Switches AdjustSfx to use the AdjustSfx-specific ZipReader creation path. |
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
Comment on lines
+224
to
+228
| if (isUnadjustedSfx) { | ||
| long actualCenEnd = | ||
| (zipData.isZip64() && zipData.getZip64EndOfCentralDirectoryOffset() > 0) | ||
| ? zipData.getZip64EndOfCentralDirectoryOffset() | ||
| : eocdLocation; |
|
✅ Bazel docs preview is ready! Preview URL: https://bazel-pr-30685.mintlify.app/ Updated for |
ted-xie
reviewed
Aug 12, 2026
ted-xie
left a comment
ted-xie
left a comment
Contributor
There was a problem hiding this comment.
Thanks! There have been a few problems reported with the AdjustSfx and modified singlejar logic so I think all of that may need some re-architecting in the near future.
| @Test | ||
| public void testZip64_WithZip32Offsets() throws IOException { | ||
| // A zip file with Zip64 EOCD and Locator, but with non-overflowing 32-bit values in EOCD (as generated by Python / standard tools for archives with Zip64 entries). | ||
| byte[] data = new byte[] { |
Contributor
There was a problem hiding this comment.
This huge array will be unpleasant to maintain, but it's fine for now.
ted-xie
added
team-OSS
Contributor
|
@bazel-io fork 8.8.0 |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Description
Fixes #30681.
In commit b12c06a (#30530),
ZipReader.readCentralDirectory()was modified to compute the central directory start asactualCenStart = actualCenEnd - zipData.getCentralDirectorySize(), replacing the parsedzipData.getCentralDirectoryOffset().This broke reading standard Zip64 archives where 32-bit EOCD fields do not overflow (as the 76-byte Zip64 EOCD and locator sit between the central directory and the 32-bit EOCD, shifting the computed offset 76 bytes into the central directory) or when
centralDirectorySizeis0xFFFFFFFF.This change:
ZipReader's standard central directory parsing to usezipData.getCentralDirectoryOffset().centralDirectorySizeinZip64EndOfCentralDirectory.read().AdjustSfx.ZipReaderTestcovering Zip64 archives with valid 32-bit EOCD offsets.