paths: resolve windows short names

[connor4312]

It uses sync, which is spooky, but I did not really want to update every
single usage of the prompt path service for something that is a very
edge case and that should be handled be the LRU generally.

Closes microsoft/vscode#278527

[connor4312]

And yes, unfortunately Node does not seem to have any built-in bindings to do this and realpath does not resolve 8.3 short paths in spite of what language models try to tell you 😛

[Copilot]

Pull request overview

This PR adds support for resolving Windows 8.3 short filenames (e.g., PROGRA~1) to their long form (e.g., Program Files) in the prompt path representation service. This addresses an issue where AI model responses containing short Windows paths would not be properly resolved back to their full paths. The implementation uses a node-specific service override with LRU caching to minimize expensive shell calls, and only resolves short paths on Windows platforms.

Key Changes

• Created PromptPathRepresentationServiceNode that extends the base service with 8.3 short path resolution logic
• Implemented segment-by-segment resolution with LRU caching to reuse directory prefix resolutions across multiple files
• Used PowerShell's GetFullPath via execFileSync to resolve short paths, with environment variables to prevent shell injection

Reviewed changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated 6 comments.

File	Description
src/platform/prompts/node/promptPathRepresentationServiceNode.ts	New node-specific service implementation with 8.3 short path detection regex, segment-wise resolution algorithm, PowerShell-based resolution, and LRU cache for performance
src/platform/prompts/test/node/promptPathRepresentationServiceNode.spec.ts	Comprehensive unit tests with test subclass that mocks shell resolution, covering single/multiple short segments, caching behavior, error handling, and integration with URI APIs
src/extension/extension/vscode-node/services.ts	Service registration for the new node-specific implementation, overriding the common service with platform-specific behavior

[Copilot]

The regex pattern for 8.3 short names is incorrect. According to the 8.3 naming convention, the base name can be up to 8 characters (not 1-6), and the tilde-number suffix is part of those 8 characters. For example, "PROGRA1" has 6 chars before the tilde, but valid short names like "ABCDEFG1" would have 7 chars before the tilde. The pattern should be /^[^~]{1,8}~\d+$/i to match the actual 8.3 format, or more precisely /^.{1,6}~\d+$/ since the characters before the tilde (plus the tilde and digit) should total at most 8 characters for the base name.

[connor4312]

copilot is wrong here, an 8.3 name can be up to 8 characters and therefore the prefix length can be 6 characters followed by a tilde and a digit

[roblourens]

I did not really want to update every single usage of the prompt path service

If you want to do it async, I think it's fine to fork a service like this to a version that's just used for the agent, so you don't spend any time updating chat participant usages.

[aeschli]

@connor4312 Can we hold off this change a bit?
I want to ask @bpasero tomorrow how we handle the normalization of file names in VS Code.
It looks wrong to be to do this somewhere deep in the code that construct user/system messages.

• How did these URI get constructed? Likely there many other places that will fail the comparison.
• In the original bug request the user voluntary starts the workspace on short path. Is that a realistic scenario? I think I've never run into such an issue.

[connor4312]

1. I think opened their workspace folder using a short name. I'm not sure exactly where/when things got canonicalized in our whole stack.
2. Maybe @waldekmastykarz can weigh in here

[aeschli]

Let's first discuss the need of this fix.

• Is it a common scenario?
• How many dups and votes we have for this?

[bpasero]

It uses sync

👎

[bpasero]

In VS Code we are not doing any such path normalisation, other than path.normalise for the path you open. That means the 8.3 form is kept in paths in that workspace and every API.

Node.js itself provides a method you can use to expand these paths: fs.realpath.native. One thing to note is that this method resolves subst drives to their original paths and I think symlinks are resolved as well so it might not be doing everything we want.

[connor4312]

TIL

> fs.realpathSync('C:\\Progra~1')
'C:\\Progra~1'
> fs.realpathSync.native('C:\\Progra~1')
'C:\\Program Files'

That means the 8.3 form is kept in paths in that workspace and every API.

Makes sense, I think though there will be mismatches though if files are seen by other apps or the terminal. But not sure how frequently this path gets hit.

[aeschli]

We need to look at all paths that are emitted by tools. Such path can be the result of from NodeJS fs operations, codebase searches and terminal output.
Such paths need then to be normalized to match the style as used in the VS Code running instance. If VS Code was opened a short name path, then all workspace folders will contain the short name and all external paths also need to normalized to include that.

IMO we should only dive into that adventure if this is a problem hit by many users.

[bpasero]

Btw there is a popular ask in microsoft/vscode#130082 to always force the file paths (including the workspace) to be in their expanded form to avoid these issues.