fix(mcp-validation): fold string sort checks UPPERCASE to match NTFS $UpCase#493
Merged
Merged
Conversation
…$UpCase T59 (`*.txt --sort path`) failed on a real C: drive: UFFS returned `…\$RJCH036\cli flow.txt` before `…\$RJCH036\_run\baseline.txt`, and the harness flagged it "not asc". UFFS is correct — the validator was wrong. UFFS sorts string columns (name/path/ext) with the NTFS `$UpCase` table, the filesystem-native collation Explorer and the NTFS index B-tree use, which folds to UPPERCASE. The harness folded `.to_lowercase()`. The ASCII gap 0x5B..=0x60 (`[ \ ] ^ _ \``) sits BETWEEN `Z` (0x5A) and `a` (0x61), so `_` orders AFTER letters under uppercase but BEFORE them under lowercase — flipping the expected order for any path/name with such a char adjacent to a letter. - Sort-check string fold: `.to_lowercase()` -> `.to_uppercase()` (covers both asc and desc branches; they share the folded `vals`). - Name-tiebreaker check (within equal path_only): same lowercase -> uppercase. - Comments on both sites explain the `$UpCase` / 0x5B..=0x60 rationale so it is not "corrected" back to lowercase. UFFS itself is unchanged; this only fixes the conformance harness so its ascending/descending assertions model UFFS's real (NTFS-native) collation. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
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.
Why
T59 (
*.txt --sort path) failed on a live C: drive: UFFS returned…\$RJCH036\cli flow.txtbefore…\$RJCH036\_run\baseline.txt, and the harness flagged it "not asc". UFFS is correct; the validator was wrong.UFFS sorts string columns (name/path/ext) with the NTFS
$UpCasetable . the filesystem-native collation Explorer and the NTFS index B-tree use . which folds to uppercase. The harness folded.to_lowercase(). The ASCII gap0x5B..=0x60([ \ ] ^ _ \``) sits **betweenZ(0x5A) anda(0x61)**, so_` orders after letters under uppercase but before them under lowercase, flipping the expected order for any path/name with such a char next to a letter.What
.to_lowercase()→.to_uppercase()(covers both theascanddescbranches . they share the foldedvals).path_only): same lowercase → uppercase . it had the identical latent bug.$UpCase/0x5B..=0x60rationale so it is not "corrected" back to lowercase later.UFFS itself is unchanged . this only fixes the conformance harness so its ascending/descending assertions model UFFS's real (NTFS-native) collation.
rust-scriptcompile-check passes.🤖 Generated with Claude Code