Repository navigation
fix(trust): stop printing extended-length path prefixes - #12014
Conversation
`mise trust`, `--untrust` and `--ignore` canonicalize before reporting, and
on Windows that hands back `\\?\C:\...`. mise refuses that form as *input*
-- `validate_path_string` calls extended-length and device paths unsupported
-- so reporting one offers a path mise itself would not accept. The
still-trusted-via-settings warning was worse: it printed through `{:?}`,
doubling every backslash on top of the prefix.
Two layers had to change. `PathExt::display_user` is the one place mise
turns a path into text for a person, and it passed the prefix straight
through, so even the call sites already using `display_path` leaked. It now
goes through `dunce::simplified`, which strips the prefix only when the
result still names the same file -- verbatim UNC, device paths, reserved
names and paths past MAX_PATH keep it, since those do not resolve without
it. The five trust.rs sites that bypassed `display_path` entirely now use it.
dunce 1.0.5 was already in Cargo.lock as a transitive dependency, so this
adds no new compilation.
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Repository YAML (base), Central YAML (inherited), Organization UI (inherited) Review profile: CHILL Plan: Pro Plus Run ID: ⛔ Files ignored due to path filters (1)
📒 Files selected for processing (4)
📝 WalkthroughWalkthroughThe change adds ChangesTrust path display
Estimated code review effort: 2 (Simple) | ~10 minutes Merge Risk: ⚪ Minimal · up to The change is a localized Windows path-display fix with no actionable merge-blocking risk remaining beyond normal checks and review. Suggested reviewers: Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Greptile SummaryThis PR normalizes user-facing Windows paths without changing the canonical paths used for trust matching.
Confidence Score: 5/5The PR appears safe to merge. No blocking failure remains. Important Files Changed
Reviews (2): Last reviewed commit: "fix(trust): stop printing extended-lengt..." | Re-trigger Greptile |
mise trustcanonicalizes a path before reporting it, andstd::fs::canonicalizereturns theextended-length form on Windows. That form reaches the user:
The warning on the last line is the same path printed through
{:?}, so Debug doubles everybackslash on top of the prefix.
mise refuses this form as input.
toolset::tool_request::validate_path_stringanswers apath:value beginning with it with "extended-length and device paths (\\?\,\\.\) are notsupported", and
windows_path_separatorsdeliberately leaves such a prefix alone rather thanrewriting it into something that "looks right and does not resolve". Handing one back in a message
offers the user a path mise itself would reject.
Scope
Measured on 2026.8.2 windows-x64:
mise trust,mise trust --untrustandmise trust --ignoreeach emit the prefix.
trust --show,config ls,doctor,env,tasks,lsandbin-pathsemit none. Consistent with the source — the only
canonicalize()results printed anywhere in thetree are trust's three.
Two layers, and why one is not enough
PathExt::display_useris the single place mise turns a path into text for a person, and onWindows it was
to_string_lossy()— the prefix passed straight through. So the two sites intrust.rsthat already calleddisplay_path(the git-worktree warning) leaked as well. Fixingonly the call sites would not have fixed those.
It now runs the path through
dunce::simplifiedfirst, which strips the prefix only when theresult still names the same file. Measured against dunce 1.0.5 rather than assumed:
Those declines are the right answer: such paths do not resolve without the prefix, so simplifying
them would produce exactly the "looks right and does not resolve" string
windows_path_separatorsavoids.
The five
trust.rssites that bypasseddisplay_path— three.display()and two{:?}—now use it.
Deliberately unchanged
canonicalize()itself is not swapped fordunce::canonicalize(). Trust matching comparesit against
Settings::trusted_config_paths(), which canonicalizes too; both sides are verbatimtoday and agree. Changing one side's shape would break the comparison. This is a display fix only.
~substitution stays unix-only. Thecfg!(unix)guard indisplay_useris a separatedesign decision, untouched here.
MAX_PATHkeep the prefix, per above.Dependency
dunce = "1"becomes a direct dependency.dunce 1.0.5was already inCargo.lock—gix-discoverand others pull it in — so the only change to the lock file is one line adding it to mise's own
dependency list, and no new code is compiled. On non-Windows
simplified()returns its input, sothe call needs no
cfg.Verification
Every claim above was measured on this host: the three leaking commands and the seven clean ones,
the
{:?}warning, anddunce::simplifiedagainst the eight shapes listed (a small cargo probe,the same approach used for
std::env::split_pathsin #12012).Tests:
src/path.rs, which had nodisplay_usertests: the drive form is simplified, and an ordinarypath, a real UNC path, verbatim UNC, a device path and a reserved name are all left alone. The
unix test pins the
~substitution the refactor had to preserve.e2e-win/trust_display_path.Tests.ps1:trust,--untrustand the trusted-via-settings warningreport the path with no prefix and no doubled backslashes, while still naming the directory — so
the assertion cannot pass by the path vanishing. It matches the prefix as a literal, since
PowerShell's
-BeLikewould read the?as a single-character wildcard.cargo fmtwas run locally. The build, clippy and the test suite were not — those are left toCI, so behaviour after the fix rests on the measurements above and on the tests rather than on a
running binary.
Found while auditing Windows behaviour, the same pass that produced #12007, #12008, #12012 and
#12013. No existing issue or discussion covers it.
Summary by CodeRabbit