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!

[bpasero]

@delmyers I suggest you ask over at https://github.com/Microsoft/vscode-cpptools/issues how it is possible that paths with wrong casing are entering the system in VS Code. You can CC me so that I can learn more about why this problem happens only with the C++ debugger (I have not heard this from any other debugger so far).

[martincohen]

@bpasero I did, they will try to normalize the paths, but this is a bigger issue. It is happening all the time on Windows, it's not a problem specific to cpptools, but rather anything that is Windows-only (cmd commands, toolchains, etc.), also different Win32 APIs return different case in paths. This has to be handled in the vscode (as per #12448 and related such as #18718).

[bpasero]

Great to hear that they try to normalize 👍

[martincohen]

@bpasero As I said and posted in the last image in previous comment, it's not only problem of the debugger, but entire Windows. In the image above you can clearly see that even VS Code command line dosen't normalize. So any toolchain can do this no matter what contract you try to force upon Windows users.

[bpasero]

I am not sure how i can acknowledge that more than pointing you to an existing bug? Did you actually look at it?

[martincohen]

@bpasero I've seen the #12448 (I haven't seen you mention it in this thread, but I know and read about it), though I got an impression that we're still debating whether it's cpptools and vscode and therefore had the urge to stress my point.

Sorry, I've been filing bugs left and right, and answered the same questions in multiple threads on both cpptools and vscode for two days now, so I'm a bit edgy. So thanks for the discussion, I'll keep my eye on #12448. <3

[isidorn]

Closing as dup of #12448 and #22740