Add option to always open files at their canonical path

Problem

Symlinks can sometimes lead to the same files being opened more than once in VSCode. An example in which this happens is in a bazel run sandbox, which symlinks files together into a sandbox environment. Another example I’ve seen is when python modules (spread over various folders in a git repo) are symlinked into 1 virtual env python path tree. More generally speaking, symlinks are sometimes used by build tooling to create one consolidated environment out of files spread over different places.

Unfortunately, this can lead to a poor user experience in VS Code. Debuggers can start opening multiple copies of the same file (the one you’d like to edit, which likely is under source control, and one at the path at which it appears in the sandbox) and the UI/UX experience is clumsy at best (breakpoints can be set in each copy of the file and actually work for both, but visually aren’t synced). Language servers like pylance can resolve imports to the symlinked venv. So opening the definition of a function can open the symlinked copy, rather than the original (which is likely under source control and the one that you’d actually like to edit)… Again: clumsy UI/UX, such as that that symlinked copy doesn’t show source control change info (lines added/rm/changed, gitlens).

Proposed solution

I’ve seen various tickets related to this and generally things seem to get stuck in the discussion on defining a solution. I’d like to take another attempt at that.

How about we introduce a boolean option openFilesAtCanonicalPath (which people can set on a user or a workspace level)?

The “canonical path” would be the path that readlink -f {some_path} would give on linux: i.e. the path with all symlinks resolved. This is the ‘original’ path for the file. This would:

1. Make sure there’s always only 1 copy of a file opened
2. Have the file opened at the path that the user is most likely interested in. If it’s part of the workspace, then this would be the path that is under version control (and all things like git/gitlens would work). If it’s not part of the workspace, so be it, it’s likely some system level dependency or so, still you’d be looking at the original file, which is great).

I wonder what VS Code devs thinks of this.

Related tickets: https://github.com/microsoft/pylance-release/issues/478, https://github.com/microsoft/vscode/issues/34627, https://github.com/microsoft/vscode/issues/100533, https://github.com/microsoft/vscode-python/discussions/15897

Final remarks

We could even expand this idea to extensions if desired (extensions could retrieve both the requested path and canonical path of a file through extensions api), though I think many of the discussions around better extension support for symlinked files are maybe already solved by just opening the canonical file instead.

Please note that I’m focussing purely on this problem as introduced by symlinks in macOS and Linux. I’m not sure about Windows or other types of links like hard links, macOS aliases, etc. So far, I’ve seen build tooling use symlinks for these kind of things so addressing that can hopefully solve the majority of issues out there.

[vscode-triage-bot]

This feature request is now a candidate for our backlog. The community has 60 days to upvote the issue. If it receives 20 upvotes we will move it to our backlog. If not, we will close it. To learn more about how we handle feature requests, please see our documentation.

Happy Coding!

[jll63]

This has not been fixed yet? This is so annoying.