Windows Debugger breaks on lowercase filename

[dclarkNV]

• VSCode Version: 1.5.3
• OS Version: Win10

Steps to Reproduce:

1. Create an .exe that uses mixed case filenames. i.e. Source.cpp
2. Add a breakpoint to Source.cpp
3. Debug and hit the breakpoint

The editor will open up source.cpp alongside Source.cpp. The arrow pointing to the current line is in source.cpp, the breakpoints are in Source.cpp. It's pretty confusing. Both files can have their own sets of breakpoints now.

[isidorn]

Please file this issue aginast the vscode cpp extension here https://github.com/Microsoft/vscode-cpptools
Thank you

[delmyers]

@weinand, @isidorn

I don't think that this is an issue with the C++ debugger. It seems that the vscode shell isn't correctly understanding that Windows file names are not case sensitive, and will open duplicate files on Windows if the paths to the files differ only in casing. This is similar to, for example, not understanding that two different relative file paths point to the same file. The editors should do proper checks to ensure that they only open one copy of the file.

[isidorn]

We use URI as an ID for files internally and it seems that the workbench handles these URIs as case sensitive. Not sure if we want / can change that.
With the initiliaze request vscode notifies the adapter that it deals with paths - so this might imply that vscode should massage all wrongly cased paths coming from the adapter if platform is windows.

@weinand let me know what you think
@bpasero any suggestions if this should be handled on the workbench side?

[weinand]

Ideally, this problem would not occur if all involved VS Code components would only use the file path with the real character case from disk (so that no differently cased paths get introduced).

However, in real life it is always possible that a path with a different case gets introduced by a component that VS Code cannot control (e.g. a path in an executable created by a compiler/linker).

The correct place to address this is when searching for a file in a workspace. So when a debug adapter returns a file path, the VS Code debug UI would not use the path as an URI that is expected to exist under the exact URI but instead it initiates a path search that takes the case sensitivity of the platform into account.

Until this has been fixed in VS Code, I suggest that debug adapters try to fix paths on their end. So if a path returned by a runtime/debugger doesn't match the casing of a file on disk, the debug adapter would correct that path before returning it to VS Code.

[delmyers]

@weinand, @isidorn

OK, we will look at fixing it on our end as well, but we will keep this bug open.

[martincohen]

The issue of case-insensitivity on Windows is basically breaking everything with my experience in C/C++ development, especially when using MSVC toolchain. I have duplicate files opened most of the time (that are not with same path, therefore they function as two distinct files):

The problem often (like every 5 minutes) results in this:

Which in turn results in a lot of changes being lost, or serious time wastes in trying to merge the two files.

In my humble opinion, this is a major issue in the vscode core for anyone trying to use Windows-only command-line tools. And so it is a problem for extension creators on Windows.

Also it is very easy to get to this state (using MSVC cppvsdbg), which is the biggest problem:

1. Open a file from Explorer.
2. One of the following:
   a. Put breakpoint to a C/C++ file. Run debug and get a new file instance.
   b. Open an issue from Problems view and get a new file instance.
   c. Open a file from external application with different case in the path (cmd, Total Commander, etc.) and get a new file instance.

In fact you can have dozens of instances of the same file.

[isidorn]

@martincohen thanks for reporting this issue. Can you please file a new seperate issue so this finding does not get lost, as the current issue is mostly about the debugger, and your issue is a general vscode issue (in the end they might have the same root cause but I would like to have then seperate).
Thanks!