Open file links from console or compile output

[hensz]

• VSCode Version:1.45.1
• OS Version: Windows 10.0.18363

Hi!

When I either do a compilation in the integrated terminal or with a build task and I click on a file "link" for an error or a warning, the file is opened differently than when I open it from the Explorer pane.

Files opened from the Explorer pane are displayed with a relative file path (relative to the workspace root I assume). However, since the file names in compiler output have absolute paths (at least in my case, not sure of this can be changed somehow) the file is also opened with absolute file path. My assumption is that now VSCode "thinks" that this is a different file than the one opened from Explorer. Therefore the file is opened twice, which causes quite some confusion, especially both variants can be edited simultaneously, eventually resulting in conflicts during saving the second one.

Also the search is affected: If a file was opened from the compile output each search results in that file are displayed twice, once in the regular list of results, and once under "Other files".

Steps to Reproduce:

1. Open a file from the Explorer, create a compile error
2. Compile this file from VSCode
3. Click the link to the file in the compile output
4. Now the file is opened twice.

[vscodebot]

(Experimental duplicate detection)
Thanks for submitting this issue. Please also check if it is already covered by an existing one, like:

• Multiple editors open for the same file (#25568)

[hensz]

btw, thanks vscodebot for suggesting this possible duplicate. I'm not sure however if this is indeed a duplicate or a different issue. Especially here I'm working with VSCode on Windows, but using Remote Development on a Linux machine. So for the Windows VSCode the two file name variants might not be that easy to interpret as "equal" - but perhaps they can be interpreted as "equal" by the Remove Development extension?

[hensz]

btw, I just realized that also "C++: Switch Header/Source" has this issue, it opens the file with absolute path, i.e. outside of the VSCode workspace.

[Tyriar]

I cannot reproduce this, either with relative or absolute links in the terminal.

Could you first try the new terminal links using this setting:

"terminal.integrated.experimentalLinkProvider": true

If it still happens can you take a screenshot of the following and post here:

• The link that causes the problem
• The explorer item you opened
• A screenshot of the tooltip when you hover both file tabs

[hensz]

Hi Tyriar!
The issue also occurs when I use the new terminal links setting: When I click the link the source file is opened with absolute path, which is considered as "outside of the repository".

As I explained in my second comment, I'm using Remote Development. When I worked natively on Linux the issue didn't occur, so I assume that it's caused by using Remote Development with VS Code on Windows and the source code residing on Linux.

Let me build a small example outside of my productive development workspace to reproduce the issue, so I can safely post screenshots and further information here.

Thanks,
Torsten

[hensz]

Hi!
As first reproduction scenario I simply set up a dummy project, opened a header and cpp file, then executed the Switch Header/Source command. The attached screenshot is the result: The header is opened twice: previously with relative path ./ and after executing the command with absolute path /data/.../test.

[hensz]

I cannot easily reproduce the build error issue with this dummy project. We're using cmake with a custom wrapper around. This cannot be setup so easily for my dummy project.

When I simply execute gcc with my sources, e.g. gcc struct.cpp, the compiler output only contains relative paths, and opening these links doesn't work.

With our cmake project we get error messages with absolute paths. But since VS Code uses relative paths for files from the workspace, opening these links with absolute paths causes this issue.

[Tyriar]

@bpasero maybe duplicate of #12448? See #98593 (comment) that struct.h is showing up as 2 tabs

[bpasero]

Can you try to reproduce with our nightly insider builds? You can give our preview releases a try from: https://code.visualstudio.com/insiders/

[hensz]

Hmm, the latest insider build doesn't work for me, remote connection fails:

Install and start server if needed
"install" process failed: TypeError: g.onDidWriteData is not a function
g.onDidWriteData is not a function

[bpasero]

@hensz what remote is that, WSL?

[hensz]

No, it's a native Linux I connect to via ssh - i.e. a different machine.

[bpasero]

@roblourens @Tyriar do you know anything about onDidWriteData, it looks like we have removed this API and maybe this is an old extension host trying to use it?

[roblourens]

Can you make sure that you have the latest version of the SSH extension installed? Haven't used that API in awhile.

[hensz]

Hi!
Thanks @roblourens, this connection error disappeared after the SSH extension was updated.

But besides that the initial problem is still effective: When running the command Switch Header/Source the respective file is opened "outside of workspace", same for clicking links in compile errors.

Just to clarify: With our compilation setup (cmake with gcc) we get compile errors with absolute paths. In my example with only using gcc directly the compile errros contain relative paths, and here clicking on the file links doesn't work at all.

[bpasero]

@hensz to clarify this only happens in a remote connection, not locally right? And you are connecting to a SSH that produces output with file links that you click on from the output window? Or is that the terminal?

[hensz]

Hi!
I only use VS Code natively on Linux very seldom these days. But after I tried it again (with x-forwarding it's really slow - Remote Development is a great help here!) I can confirm that the issue also occurs natively without Remote Development (I only tried the Switch Header/Source command).

Perhaps this is related with how we've set up our project. I've simply opened the folder in VS Code, but also I set the compileCommands setting to a compile_commands.json generated from our cmake configuration. Perhaps this configuration is behaving "strange".

To validate if the compileCommands is causing this issue, can you tell me what information Switch Header/Source is using, and how file paths are interpreted in compile errors (wrt. relative or absolute paths)?

[bpasero]

Sorry, I do not follow. Can you copy a path from the explorer and then copy a path from the editor to compare it and paste the results here?

[hensz]

In my example above the workspace is located in this folder:
/data/user/workspace/test

In this folder I have two files, struct.h and struct.cpp. When I open these files from the Explorer in VS Code, they are opened with relative paths, i.e. ./struct.h and ./struct.cpp respectively. When I open the header for the cpp file with Switch Header/Source the header ist opened with absolute path, i.e. /data/user/workspace/test/struct.h. As you can see in the screenshot I posted 3 days ago this file is now opened twice.

So to me it seems that the command Switch Header/Source determines the respective other file with some heuristic or from some information from the workspace (e.g. from compile_commands.json) for some reason with absolute path, while normally files from the workspace are considered with relative paths (relative to the workspace root).

Also when I get a compile error, the files are printed with absolute paths, e.g. /data/usr/workspace/test/struct.cpp - and when I click this path, this is considered as a different file than the one from the workspace, since VS Code "knows" this one as ./struct.cpp.

[bpasero]

@hensz

Then I open the header for the cpp file with Switch Header/Source

VSCode does not support this, so you are using an extension for it? Then please report it against the extension, I cannot control what the extension is doing.

Can you PLEASE follow the steps and:

• Right-click copy path for an explorer file
• Right-click on tab of a file that shows with absolute path and copy path

Paste both here.

[hensz]

Hi!

Now that was a real help!

I totally forgot that I'm using a symbolic link for my workspace. The "physical" folder /data/usr/workspace is represented by a link /workspace. And the workspace I opened in VS Code is exactly this link: /workspace/test.

So both paths from explorer and the file opened from the explorer is using the symlink:
/workspace/test/struct.cpp
The file with absolute path, opened either with Switch Header/Source or from the compile output is:
/data/usr/workspace/test/struct.cpp

I think this is the root cause of the issue. Let me check what happens when I open the workspace with the "physical" path... Yes, now the path is always the same, the "correct" one so that VS Code considers the file as part of the workspace.

So from my perspective we could either close this issue as "PEBCAK", or we could try to solve the different handling of pathswith symbolic links. It's definitely possible to determine that a path contains a symbolic link and resolve this link - this is exactly what "Switch Header/Source" and our build mechanism does, so also VS Code could do that. But fixing this is definitely not a high priority for me :-)

Thanks a lot for the help to identify the actual root cause!