Repository navigation
Conversation
…folders, resource forks) The reader understood only a classic SIT! subset with store/RLE, checked forks with the wrong CRC (CCITT instead of ARC), read 63-byte names into fields that start at byte 34, had no folders and no StuffIt 5 layout, so none of the sample archives made by real StuffIt installs extracted. The writer shared the CRC mistake and wrote RLE90 runs one byte short. Reader: classic SIT! (header CRC-16/ARC verified, folder start/end records, 31-byte names, Mac Roman) and StuffIt 5 (entry versions 1 and 3, nested folders, comments, resource-fork records). Forks decode with method 0, 1 (RLE90), 2 (compress LZW, 14-bit block mode), 3 (Huffman), 5 (LZAH), 13 (LZ+Huffman) and 15 (Arsenic), each verified by its CRC-16/ARC or, for Arsenic, its CRC-32; methods 8/14 and encrypted forks are listed and refused. The descriptor lists folders and exposes resource forks as "<name>.rsrc". Writer: CRC-16/ARC for header and forks, BinHex-style RLE90 run lengths, names longer than the 31-byte field are refused instead of corrupting the header. Oracle: four archives made by StuffIt Deluxe 4.5 / 6.5.1 / 7.0 (Mac OS 9) and StuffIt 7 (Windows) from ssokolow/stuffit-test-files (CC0) are committed; every data and resource fork matches the SHA-256 of the source file it was made from. unar (The Unarchiver) extracts the same bytes from them and from archives our writer produces; a tool-gated test also compares any local samples (CWB_STUFFIT_SAMPLES - the dexvert set covers methods 2 and 3). Sourcing: rung 1 - converted from XADMaster (LGPL-2.1-or-later, revision 7cb9ee0), notice in THIRD-PARTY-NOTICE.XADMaster.txt; method-13 code tables and the Arsenic randomisation table copied verbatim.
Retain StuffIt and main reference archives together, record the pinned XADMaster conversion notice, preserve current archive capability descriptions and keep main artwork. Verified: Release solution build; 124 focused format/documentation/provenance tests passed with 10 tool-dependent skips, 23 architecture checks and 2 archive support-matrix checks passed; generated API documentation matched without changes.
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.
The StuffIt reader only handled a classic SIT! subset with store/RLE and checked forks with the CCITT CRC-16, while StuffIt (and The Unarchiver) use the ARC/IBM CRC-16 - so real files failed. Rewritten: classic SIT! (header CRC-16/ARC, folders, 31-byte names) and StuffIt 5 (entry versions 1 and 3, nested folders), methods 0/1/2/3/5/13/15 each verified by CRC-16/ARC or Arsenic's CRC-32; 8/14 and encrypted forks refused. Resource forks list as
<name>.rsrc. Writer: ARC CRCs, correct RLE90 run lengths, names >31 bytes refused.Verified: four archives made by StuffIt Deluxe 4.5/6.5.1/7.0 (Mac) and StuffIt 7 (Windows) from ssokolow/stuffit-test-files (CC0) are committed; every data and resource fork matches its source file's SHA-256. unar extracts the same bytes from them and from what our writer produces. Rung 1: converted from XADMaster (LGPL-2.1+), notice included.