Vscode: Support symbolic link folders in areas like debug, extensions

[livcurious]

• VSCode Version: 1.16.1
• OS Version: macOS sierra 10.12

Steps to Reproduce:

1. Open a empty workspace
2. Create a file and create a symlink to this file in workspace.
3. On opening the file, the linked file will be open in the editor. The path (on hovering over the opened file name) will be shown for the symlink and opening the file in Finder by right clicking will also open the symlink's parent folder.

The issue with this is it also causes inconsistency with Git markers in enhanced scrollbar and all extensions which operate on open file (like gitlens for git blame).

There should be a editor property to configure this path to be set as original file's path or the symlink's path.

Reproduces without extensions: Yes

[mfine15]

What's the status of this? It'd improve the UX of working with C++ projects using clangd + Bazel. Jump to definition will jump to the symlink in bazel-genfiles, even if you already have the target of symlink already open in Vscode.

[axiac]

In my opinion, the symlinks should never be replaced with the real paths they point to. If one component of a path is a symlink then there is a reason behind it. If VSCode resolves the link and uses the real path instead then it breaks the reason the symlink exists. On the other hand, the user could not use the symlink at all and open the project or the file using its actual path; VSCode doesn't bring any improvement here by resolving the symlinks.

[froodian]

The issue is that if you have a symlinked directory inside your workspace (e.g. in a git repo), git tooling no longer functions for files inside that directory.

[bpasero]

This is not just one issue but many things to support. I renamed the title to reflect that.

[joaomoreno]

For git: #5970

[ghost]

This also occurs if your project is on a different partition and you have a symlink to the parent directory of the the project folder. vscode will follow the symlink path instead of the real path.

Say you have ~/projects -> /mnt/data/projects
vscode will open a file using this path ~/projects/pro1/file instead of using the absolute path.

This prevents git markings from showing and you have to manually refresh the source control to see the changed files list.

My work around is replacing the project path from "." to the absolute path to the project in the workspace file:

"folders": [
    {
        "path": "/mnt/projects/pro1"
    }
],

but unfortunately I can't commit this to the repo.

[mawright]

This seems to cause a difference between which editor windows get git annotations and are opened by the debugger (in Python with Microsoft vscode-python at least).
The "real" file gets tracked by git and gets gutter annotations and viewable git history, but the debugger always wants to open and follow lines in another editor window whose file is in the "virtual" directory that follows the symlink.

[SebastianMauchly]

The case I'm encountering is similar to @mfine15's: we have a Build folder inside the project directory where we put all built artifacts from a multi-language repo that happens to include some python. For development installs (as opposed to a deployment), we just create a bunch of symlinks for all the python stuff. That way it's easier to iterate, but the Build folder still looks like it would in a deploy. So I have:

Build/
-bin/
--some_executable
-python/
--myfile.py (symlink to ../../Source/myfile.py. This is the path I actually launch)

Source/
-myfile.py (Real file I want to have open, see git annotations on, set breakpoints, etc.)

Trouble is, if I set a breakpoint in the source file and then run, the debugger hits the breakpoint and opens that file in a new editor, since it considers the symlink to be separate. The debugger is stopped, but to un-tick the breakpoint you'd have to navigate back to the real source file, since it doesn't show up in the gutter of the new editor. Also, if you make the mistake of trying to set another breakpoint in the "symlink" version further down, you now have breakpoints across two files, and it turns into a headache. Worse, the debugger is constantly expanding the Build/ tree in the explorer panel to bring focus to the Build/ version of the file. Thus I have to scroll through 2 versions of my repo to find things, when I had hoped to keep the Build products collapsed the majority of the time.

One thing I like about code is that it always chooses to re-focus an existing editor if you try to open a file you already have open (rather than opening the same file in two separate tabs). In the spirit of not violating that pattern, I don't think it should be treating a symlink path as separate in this context.

[DmytroSokhach]

Still actual after 3 years. MacOS.
When you have NodeJs multi-repo, and have linked workspaces it is hard to navigate between them.
E.g.:

• core
  |-- base.ts
• server (has symlink to "core" using "yarn link" or "npm link"
  |-- index.ts (has "import * from "core")

When navigating with Ctrl+Click inside /server/index.ts on anything from core it navigates to /server/node_modules/core/base.ts and shows errors, no more intellisense.

[ashep]

+1, why this still isn't fixed? It's unbelievable that just a few people faced this disappointing issue...

[koliyo]

Wow, this issue is causing me so much headaches due to VS code opening same file in multiple tabs with multiple paths (real path and symlinked path), and other problems as well

[marnunez]

Has anyone tried using bind mounts instead of symlinks?