-
Notifications
You must be signed in to change notification settings - Fork 27.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Do not fs.realpath workspace paths so that symlinks are left intact #18837
Comments
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. |
@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. |
I find myself in a similar situation with "Open 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. |
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. |
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.. |
With multi-root landing in stable soon, here is a workaround to enforce a symlinked folder path:
Format (e.g. {
"folders": [
{
"path": "<path to symlinked folder>"
}
],
"settings": {}
} You can do this today already via our insiders build: https://code.visualstudio.com/insiders |
it works |
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. |
I still got the problem while click VSCode Version: 1.19.2 |
@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
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 |
this is a bug. |
Encountering the same problem. Golang toolchain requires PWD to be in $GOPATH to work properly. Resolving symlinks breaks my golang setup. |
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. |
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. |
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! |
I have pushed a change to not follow symbolic links anymore (for files and folders). I see no reason why we would want to |
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. |
Steps to Reproduce:
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.
The text was updated successfully, but these errors were encountered: