Handle bvx2 LZFSE blocks in IWA decompression#1
Open
AirRunner wants to merge 1 commit into
Open
Conversation
Numbers Creator Studio can write bvx2 (LZFSE) instead of bvxn (LZVN) for OperationStorage.iwa. Matching the 3-byte bvx prefix instead of the 4-byte bvxn magic routes all LZFSE variants to decompressLZFSE(), which handles them correctly via compression_decode_buffer.
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
1 participant
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.
Problem
Numbers Creator Studio can write
OperationStorage.iwausingbvx2(LZFSE) framing instead ofbvxn(LZVN). The previous code matched only the 4-bytebvxnmagic, so any IWA starting withbvx2fell through todecompressSnappyChunksand raisedinvalidIWAHeader(expected: 0, found: 98).Fix
Match the shared 3-byte
bvxprefix instead of the 4-bytebvxnmagic. All LZFSE block types (bvxn,bvx2,bvx-,bvx$) share this prefix, so the existingdecompressLZFSE()(which delegates tocompression_decode_buffer) handles them all correctly without further changes.Verification
Confirmed against a real-world Numbers 15.2.1 file whose
OperationStorage.iwastarts withbvx2([0x62, 0x76, 0x78, 0x32]). Parsing succeeds after this change.OperationStorage.iwastores the document's operation history. Numbers may switch frombvxntobvx2as that history grows, which would explain why the issue doesn't surface on fresh files.