{"record":{"id":"aab4ec6da1d8617e","repo":"jdx/mise","slug":"invalid-tool-path-s-extended-length-and-devic","errorCode":null,"errorMessage":"invalid tool path {s:?}: extended-length and device paths (\\\\\\\\?\\\\, \\\\\\\\.\\\\) are not supported","messagePattern":"invalid tool path (.+?): extended-length and device paths \\(\\\\\\\\\\\\\\\\\\?\\\\\\\\, \\\\\\\\\\\\\\\\\\.\\\\\\\\\\) are not supported","errorType":"validation","errorClass":"eyre::Report","httpStatus":null,"severity":"error","filePath":"src/toolset/tool_request.rs","lineNumber":566,"sourceCode":"/// The list is written for a POSIX shell, which is why `\\` is on it. On Windows `\\` is a path\n/// separator instead, so it is rewritten by [`windows_path_separators`] before it gets here rather\n/// than being allowed through — see that function. The shell those hooks run through there is\n/// `cmd.exe`, whose metacharacters are a different set, so a few more are rejected on Windows —\n/// see [`is_forbidden_path_char`].\nfn validate_path_string(s: &str) -> Result<()> {\n    if s.is_empty() {\n        return Ok(());\n    }\n    if let Some(c) = s.chars().find(|c| {\n        // Allow newlines/tabs/etc. in paths is still bad — keep control-char\n        // and quote/expansion rejection, but allow `/` since paths need it.\n        is_forbidden_path_char(*c)\n    }) {\n        // The only `\\` that survives the rewrite is an extended-length or device prefix, so say\n        // what is actually wrong instead of naming a character the user cannot avoid.\n        #[cfg(windows)]\n        if c == '\\\\' {\n            bail!(\n                \"invalid tool path {s:?}: extended-length and device paths (\\\\\\\\?\\\\, \\\\\\\\.\\\\) are not supported\"\n            );\n        }\n        bail!(\"invalid tool path {s:?}: contains forbidden character {c:?}\");\n    }\n    Ok(())\n}\n\n/// Rewrite `\\` to `/` in a `path:` value on Windows.\n///\n/// `\\` is the path separator there, not a shell metacharacter, so [`validate_path_string`] used to\n/// reject every native path — anything copied out of Explorer or printed by `pwd`. Win32 accepts\n/// `/` wherever it accepts `\\`, so rewriting is what makes those usable *without* letting a `\\`\n/// reach a vfox hook's `ctx.rootPath`, which is the thing the list exists to prevent (#9814). The\n/// alternative — dropping `\\` from the list on Windows — would have weakened that.\n///\n/// Extended-length and device prefixes (`\\\\?\\`, `\\\\.\\`) are left alone. Those are the one place\n/// Windows does not accept `/`, so rewriting would hand back a path that looks right and does not","sourceCodeStart":548,"sourceCodeEnd":584,"githubUrl":"https://github.com/jdx/mise/blob/6f52dcdf99e282ef7a7db68c81301fa4618d0f79/src/toolset/tool_request.rs#L548-L584","documentation":"Error \"invalid tool path {s:?}: extended-length and device paths (\\\\\\\\?\\\\, \\\\\\\\.\\\\) are not supported\" thrown in jdx/mise.","triggerScenarios":"Thrown at src/toolset/tool_request.rs:566 when the library encounters an invalid state.","commonSituations":"See trigger scenarios.","solutions":["Use a normal path instead of an extended-length (`\\\\?\\`) or device (`\\\\.\\`) path for the tool."],"exampleFix":null,"handlingStrategy":null,"validationCode":null,"typeGuard":null,"tryCatchPattern":null,"preventionTips":[],"tags":[],"backgroundTag":null,"analyzedSha":"6f52dcdf99e282ef7a7db68c81301fa4618d0f79","analyzedAt":"2026-08-22T10:14:23.840Z","contentChangedAt":null,"schemaVersion":2},"datasetVersion":"2026-09-14T05:17:10.506Z"}