Skip to content

fix: refuse removal through ambiguous lossy paths - #82

Open
phibkro wants to merge 1 commit into
tobi:mainfrom
phibkro:fix/lossy-name-safety
Open

phibkro wants to merge 1 commit into
tobi:mainfrom
phibkro:fix/lossy-name-safety

Conversation

@phibkro

@phibkro phibkro commented Oct 11, 2026 •

Copy link
Copy Markdown

Reproduction

An invalid-UTF-8 entry and a sibling named with a literal U+FFFD share the same display name in the scan tree. A scan-derived-path test against origin/main (not included here) deleted the literal sibling and failed with lossy scanned path removed the literal U+FFFD sibling. A directory variant derives a child path through the ambiguous intermediate component.

Fix

Refuse any removal path containing U+FFFD with a clear lossy-filename error. This avoids storing native names per node (Node is size-tested). The tests keep the original collision scenario, cover ambiguous intermediate directories, and prove an ordinary non-ASCII name (café) still plans and is removed through normal dispatch while an unmarked witness survives.

Checks run

The three exact core regressions each passed (1 passed). cargo xtask lint passed. cargo xtask test passed: 72 app, 143 core (2 ignored), 3 xtask.

Limitations

The policy deliberately refuses literal U+FFFD names, and descendants of a U+FFFD-named root, too. Exact byte identity would need native names in the tree and is left for a larger change. The invalid-byte fixtures are Unix-only; Windows: cargo check -p disktree-core --target x86_64-pc-windows-msvc --tests passes; nothing was run on Windows.


Developed with AI assistance (OMP agents). I reviewed the diffs; every check listed was run on the final branch.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant