Repository navigation
Pick an entry's handle in one place, so HFS+ folders can be opened, searched and tagged - #181
Merged
Merged
Conversation
…earched and tagged HFS+ names its entries by catalog node ID (cnid); about twenty copies of the rule looked only for the other readers' keys. Expanding an HFS+ folder listed the volume root again, and search, hashing, indexing and tagging never went below the top folder. One helper (engine/nodes.py) replaces the copies in the engine and web/app.js; a test fails if one is written out again. HfsPlus can look an entry up by handle, so a tagged file can be exported. Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_017DPjyZZHvaivtvJ3N4hZhz
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.
Found while starting the cross-check harness: its walker could not descend into HFS+ folders, and the cause was a rule copied around the code base.
What changes for examiners
Each filesystem reader names its entries by its own key: MFT record (NTFS), inode (ext), object ID (APFS, logical evidence), first cluster (FAT/exFAT), and catalog node ID
cnid(HFS+). About twenty places chose among those keys, and nearly all of them leftcnidout. On an HFS+ volume that meant:Topexpanded toTop, root.txtonmain; it now expands toInner, a.txt.The change
engine/nodes.pywithnode_of/node_key; the Python copies (filesearch,hashing,artifacts,recyclebin,filetype,textindex,casedb×2,server×4,timeline) now call it. The hit dicts built by search and the store entries built by the mail sweep carrycnidtoo.web/app.js: onenodeValue()replaces ten copies.HfsPlus.entry_by_node()looks an entry up again from its key, and_entry_from_bodyuses it, so a tagged HFS+ file exports its content, not an empty file.tests/test_nodes.py(12 tests): the rule, HFS+ walking and keying through the real walker, lookup by key, the server's rebuild, and a source check that fails if a copy of the chain is written out again (Python or JS) or the two key lists drift apart. 7 of its tests fail on the old code.Verification
Does not fix the empty root listing seen on one real volume (that is a different problem, being chased separately).
🤖 Generated with Claude Code
https://claude.ai/code/session_017DPjyZZHvaivtvJ3N4hZhz
Generated by Claude Code