IntelliSense does not work if folder opened through a symbolic link

[Colengms]

This is derived from: #4569

Repro:

• On Linux, create a local directory. (i.e. 'mkdir actual')
• Create a source file (test.cpp) in that directory, with the following contents:

#if 0
int i;
#else
int j;
#endif

this should squiggle

• Create a symbolic link to that local directory. (i.e. 'ln -s actual softlink')
• Open the 'softlink' folder into VS Code.

Seeing: inactive regions are not dimmed. Squiggles are not applied.

Log output indicates that IntelliSense processing was successful against the file in the actual path, but the results are not applied. There are likely some comparisons of actual and softlink paths that are failing.

We're using realpath() to canonicalize paths on Linux and Mac, whereas on Win32 we don't try to resolve symbolic links at all. We may want to avoid using realpath(), and find an equivalent way to canonicalize paths that doesn't resolve symbolic links.

[owaink]

Just banged my head against a wall for a few hours trying to replicate my setup from my Linux laptop to my WSL desktop. Had the repo I was working on living in my Windows user folder with a symlink to it in my WSL home directory. Cloning my repo directly to my WSL home directory resolved the issue.

Commenting for visibility since it took a while to figure out what was going on with my syntax highlighting

[surban]

At least a warning should be shown when this scenario happens. It took me some time to track this issue back to this bug report.

[sean-mcmanus]

@surban Agreed. See #9498

[Uvamosk]

I spent almost 10 hours trying to track down why Highlighting would not work correctly. I was using a link on the Linux desktop to access my projects folders. Highlighting was broken when using that link but if I navigated directly to the Folder and Right click open VSCode everything worked fine.
My current workaround has been to use "Create a new launcher here" set the command to Nemo /Home/User/Myprojects
This opens up the folder and allows me to right click open with VScode and everything work correctly.

[BecauseTheWorldIsRound]

Same issue as everyone above.
Took me also a bunch of hours. Playing with config files... until I figured out that the problem was due to a symlink.
It was ChatGPT "who" pointed me in the right direction.

IMO

• the folder/workspace config should keep the path given by the user (the one that includes a symlink)
• but as soon as the Folder is clicked, a 'realpath' should be done immediately and only that real path should be used during the session (passed to interllisense/C++ compiler etc.).

[starball5]

Related on Stack Overflow: VS Code Error Squiggles do not work if the project dir is a symlink.

[xianpul]

I have same issue as well, the semantic highlighting doesn't work on files which are in a path having symbolic. It also took me 5+ hours to locate the issue.

[ericjessee]

Yet another user running into this issue with semantic highlighting through symbolic links. The team I'm working on uses workspaces with a lot of symbolic links, so it would be really nice to see this fixed so I don't have to always add the files from their true path manually.

[Daigoro96]

I am having the same issue as everyone else. Are there any workarounds?

[richbai90]

It should be noted that this is also an issue if you have symlinks in your include directory including the system include directory. The issue in my case was that /usr/include/pybind11 was a symlink to the system-packages folder of the system python distro. Any time I tried to include something from pybind11 I would get lots of red and orange squiggles.

[YonatanNachum]

Any progress on this ?

[sean-mcmanus]

@YonatanNachum Not specifically.

[wjquigs11]

Recently Dropbox on Mac changed to use the "file provider", which puts the Dropbox folder in a symlinked path, so this breaks for any Mac VS Code user who stores files on Dropbox. (Workaround is to open VS Code folders through ~/Library/CloudStorage/Dropbox instead of the provided Dropbox link).

[kt-bouse]

There is another aspect of this that I haven't seen anyone comment about: F2 rename doesn't work.
From within VSCode I opened a workspace "remotely" hosted in a WSL2 instance.
That directory tree was symlinked to a github directory on my Windows host via /mnt/d/...
Trying to refactor/rename a structure shared across multiple files failed, and the error given was
"Unable to process IntelliSense for file with same canonicalized path as existing file."

[lewis-yeung]

Trying to refactor/rename a structure shared across multiple files failed, and the error given was "Unable to process IntelliSense for file with same canonicalized path as existing file."

Same issue. Moreover, the file will be "reopened" (using the real path) next to the active editor, and the newly opened editor is marked "changed" with the very identifier renamed to what I want.

Updated: For those who don't compromise with using real paths, a workaround is to use a bind mount.

[adthoms]

@sean-mcmanus I feel that many developers would appreciate it if this bug was fixed. Being able to clone your repos into Dropbox and then symbolically link your projects to your workspace (for example) is a safe and efficient way of backing up your work without having to commit and push in-progress work that breaks the build. This has proven very useful in research, where this workflow makes prototyping much easier having access to Dropbox's version control.

[ferdnyc]

It should be noted that this is also an issue if you have symlinks in your include directory including the system include directory. The issue in my case was that /usr/include/pybind11 was a symlink to the system-packages folder of the system python distro. Any time I tried to include something from pybind11 I would get lots of red and orange squiggles.

Ooh, that's potentially nasty for macOS Homebrew users (and I guess the 3 of us who've ever installed a linuxbrew package), because basically everything in Homebrew is a symlink. The real files all live in the Cellar directory, but they're accessed from the standard-fs-layout {bin,lib,include,share} directories in /usr/local/ or /opt/homebrew/.

[crisclacerda]

Hi all and @sean-mcmanus,

This issue is quite a nasty one, essentially making the extension unusable for those relying heavily on symlinks in their environment. I’m wondering if the lack of progress means it's something deeply embedded in the extension’s inner workings or maybe even VSCode itself, or if it’s simply that nobody has taken the time to dive into the code to investigate it?

Would it be worth looking into this myself, or is it a big can of worms?

Thanks!