Paths with incorrect casing in terminal output can cause the same file be opened twice.

[Schobers]

Windows 10 x64
Visual Studio Code 1.15.1 x64
C/C++ extension 0.12.3
CMake version 3.7.2 with Visual Studio 14 2015 Win64 generator

Reproduction:

• Open a C++ project (folder) in Visual Studio Code.
• Setup a (build) task running MSBuild on a (CMake generated) Visual Studio solution and utilizing the problemMatcher "$msCompile".
• Make the build fail in some way so an error is reported in the terminal that executes the task.
• Ctrl+click the file the compiler reported (in my case this is weirdly structured as c:\project\subfolder\file.h; all lower case while actual path contains upper case characters, e.g. C:\Project\SubFolder\file.h).
• Make sure editor is kept (Ctrl+K Enter).
• Now double click the same error in the Problems tab (Ctrl+Shift+M) or open the file via the Explorer (Ctrl+Shift+E)
  Project.zip

Expected:

• The open editor tab is given focus again.

Actual:

• A second tab is opened

Notes:

• Order of opening of the tabs does not matter.
• The same issue does not happen to .cpp files in this version of CMake/Visual Studio because the casing of the paths is correct (I'm assuming the Visual Studio compiler generates the "incorrect" paths because the CMake generated .vcxproj project files are correct). Obiviously, regardless of the correctness of these tools I'd expect the single tab behaviour.

Notes on example:

• The example expects CMake to be initialized in a sub folder called Binaries (e.g. cmake .. -G "Visual Studio 14 2015 Win64" ran in C:\Project\Binaries).

[pieandcakes]

@Schobers The bigger issue here is Windows is not case sensitive so we can get either c:\project\subfolder\file.h or C:\Project\SubFolder\file.h from the symbol and then we just pass it back to VSCode to open the document. VSCode's method of opening documents is case sensitive.

[Schobers]

Should I duplicate this bug in the VSCode repository then?

[pieandcakes]

@Schobers We have tried that and they have said "won't fix" and their suggestion is for us to find a way to figure out the correct casing of the file. I've marked it a bug and we'll look at addressing it.

[ix-dcourtois]

Hi, I have the same kind of issue when debugging: if my project was built using file D:\Development\Foo\Bar.cpp, when I set a breakpoint in it, when the debugger hits it a second file named D:\development\foo\bar.cpp is opened.

This is really hurting when debugging complex projects: 10 breakpoints spread in 10 different files result in 20 files opened. And the worse thing is that the breakpoint was set on the correct cased file, but you actually break on the one with lowercase, where the breakpoints do not show ...

Anyway I hope this bug can be fixed quickly.

[sean-mcmanus]

Hmm...I'm still reproing this bug. Is anyone else?

[pieandcakes]

@sean-mcmanus Please provide logs or examples. I can't duplicate this.

[sean-mcmanus]

It repros on Windows with the cppvsdbg debugger, not with gdb.

[Schobers]

It reproduces with the scenario that @ix-dcourtois mentioned in #984 (comment). So technically it's probably a different bug then the original report since the source of the path is different (task/compiler versus debugger).

[pieandcakes]

The overall issue is: microsoft/vscode#12448

[sean-mcmanus]

The debugger casing issue on Windows is being tracked by #272 .

[0xabu]

I'm still seeing something very like this issue. How/where was it fixed?

My specific scenario is:

1. Open a file in the editor using the explorer, so it has the correct case (in this case, …/Relocation.c). Keep it open.
2. Run a build task that produces an error in this file using both the msCompile problem matcher and a build tool that lowercases all filenames (so the reported error is in …/relocation.c)
3. Click on the error in the build window (or the problem window), now I have two editors open: one for Relocation.c and one for relocation.c

[pieandcakes]

@0xabu This is only fixed for debugging, and not for build.

For debugging, we are intercepting the filename from the debugger, checking the file system for the file and returning the right casing to VS Code so it will open the file with the correct disk casing.

For Build, you would need to send that over to VS Code to address since I think all that the problem matcher does is give you the build error (which in your case is the wrong case) and then they open the document. Here is the issue on their side: microsoft/vscode#12448