Vscode: Do not fs.realpath workspace paths so that symlinks are left intact

[ghost]

• VSCode Version: 1.8.1
• OS Version: Windows 10 pro 14393.693

Steps to Reproduce:

1. Create folder c:\test
2. Create empty text file c:\test\test.txt
3. Create directory junction in d:\ to c:\test
4. Open d:\test\test.txt
5. Notice that the path is given as c:\test\test.txt not d:\test\test.txt

This can be problematic, particular when copy/pasting the path to use in other applications or using extensions for source control, e.g. Perforce as they may not recognise the file.

[bpasero]

Yes, we are using fs.realpath on any path that enters the workbench upon opening and this method follows symlinks and converts them. I feel uneasy to change this since we have been running like that for years without issues reported so far.

[ghost]

@bpasero Thanks for the clarification - I'm not a JS developer so a brief look at the source just led me down a rabbit-hole. I thought I'd used junctions and VSCode previously and seen different behaviour but checking with older versions it seems not. I can see that changing the behaviour at this point would be risky and that the choice is largely arbitrary with it being difficult to argue a case for one approach or the other and therefore hard to justify changing it.

Thanks for retagging as a feature-request, as it would certainly be nice to have.

[ivan-section-io]

I find myself in a similar situation with "Open Folder".
When opening a linked folder directly, it's dereferenced - causing problems for tools needing the original paths for files to operate on.
But if I "Open Folder" the link's parent folder, it appears to not dereference file paths in the folder.

My workaround at the moment: create an extra empty folder to act as the "Folder Open" target and parent folder for the link.

It sounds unlikely this will change because of fear of breaking existing code.
Would making this a non-default configuration setting make this change a viable option?

[rhummer]

I'd vote for a non-default configuration setting. I'm in a similar situation as ivan, but our linked folder is at the top level so it's not really feasible to use his workaround, and the folders I have vscode setup for are several layers deep. So my work around is to keep that entire folder on the 'correct' drive.

[Excommunicated]

So this bit me while using the VSTS extension on windows. We have small primary SSD drives and store our code on larger spinning drives. We have a couple of projects that require a specific path to exist from the c:\ drive, and I have symlinks to the true folders on the d:\drive. When the VSTS extension runs it uses the workspace.rootPath to do the TF workspace discovery which is always reporting as the D:\ drive..

[bpasero]

With multi-root landing in stable soon, here is a workaround to enforce a symlinked folder path:

• craft a .code-workspace file that includes the path to the folder as symlink
• open the code-workspace file (File > Open Workspace...)

Format (e.g. myWorkspace.code-workspace):

{
    "folders": [
        {
            "path": "<path to symlinked folder>"
        }
    ],
    "settings": {}
}

You can do this today already via our insiders build: https://code.visualstudio.com/insiders

[vvavrychuk]

it works

[naquin]

Another use case where this can bite is when setting breakpoints for go packages. I use symlinks in my $GOPATH for my projects, but the go debugger can't map the realpath breakpoint to its corresponding package.

I would be in favor of changing the default behavior here instead of the workaround suggested earlier.

[jettbow]

I still got the problem while click open in Terminal after applying the workaround.
It opens real path rather than symbolic path.

VSCode Version: 1.19.2
OS Version: macOS Sierra 10.12.6

[vvavrychuk]

@jettbow For terminals this won't work since they rely on PWD environment variable to get actual (non-dereferenced) current directory. So we need to either

• pass PWD environment variable to node-pty
• set PWD environment variable in node-pty itself based on opt.cwd option that we pass to it, see https://github.com/Tyriar/node-pty/pull/156/files

I personally gave up fighting with symlinks and switched to mount bind feature in places where I do not want dereference. In particular because this issue of dereference is presented in other software besides VS Code, and also I wanted to use fish shell, http://fishshell.com/docs/current/faq.html#faq-cwd-symlink

[bonafideyan]

this is a bug.

[gyf304]

Encountering the same problem. Golang toolchain requires PWD to be in $GOPATH to work properly. Resolving symlinks breaks my golang setup.

[Oblomoff]

This is not a _"feature"_ at all. This is a bug. Even when project folder is _under_ symlinked parent folder the path resolves to original folder. This breaks all relative paths pointing to items outside of symlinked folder. This behavior looks unexpected.

PowerShell Windows 10

md source
New-Item -Path .\target\ -ItemType SymbolicLink -Value .\source\
cd .\target\
md myproject
cd .\myproject\
code .

Now open Ctrl+` and look at current path. It is source\myproject.

[jtheisen]

Another instance of this issue: Some tools (webpack's copy-plugin for instance) can't handle spaces in filenames. So if your username contains spaces, you can't compile under VS Code.

[tinysnake]

this problem is a huge impact for Unity developers， because we constantly open files in the Unity Editor, not from VS Code. Please consider fix, thanks!

[bpasero]

I have pushed a change to not follow symbolic links anymore (for files and folders). I see no reason why we would want to fs.realpath paths. I left the normalisation part in as well as resolving relative paths to absolute based on the current working directory.

[bpasero]

I see no reason why we would want to fs.realpath paths.

One potential pitfall is that external tools (including extensions) might produce paths that are using the real path of the symbolic link and thus any state with those paths will never match the paths in VSCode if we preserve the symbolic link. I already noticed that we have issues with the Git extension as well as debug. Will have to see if fixes are possible.