Issues with not case/fragment-normalizing file paths (macOS, Windows)

[bpasero]

In VS Code we deal with resource URIs across all layers. In most cases we use URI.toString() to decide if a resource is equal to another resource. This assumption is not very good when we talk about file system paths because on macOS and Windows a file path should be considered equal if the paths are identical, even if the casing differs (/some/path === /SOME/path). Only Linux has a case-sensitive file system where this rule does not apply.

This leads to numerous related issues:

• Mac: chokidar file watcher does not work if you run with wrong casing (Mac: file events are not reported when using workspace path with different casing #1426)
• quick open and editors can show the same file multiple times (VSCode opens the same file in multiple editors if the names use different cases #17967, Opening a file should ignore casing if file already opened (Win, Mac) #15120, File path case-insensitivity on Windows #18718, Quick open can have duplicate entries with different path casing #6152, Duplicate entries in quick open #16824, When opening a file from problem view, the file is opened again in a new tab. #18684, Editors are identified case-sensitively on case-insensitive file systems leading to multiple editors for the same underlying file #19014, Files need to ignore hash/query portion of URIs and only check for fsPath #19398)

[bpasero]

Pushed a fix for the broken file events on macOS.

[BillDenton]

Any update on this? I keep tripping over it particularly when using the debugger.

[jameshartig]

I spent the last month fighting gopls and I had just chalked it up to gopls being in beta, but the underlying issue was that somehow VSCode was opening C:\Users\James\... instead of C:\Users\james\... I understand that it's expensive to check the casing on every file but could it at least check the casing upon opening a folder/file on initialization. I typically switch workspaces using ctrl+r and so I have no idea how long it has been the wrong case.

[bja-ableton]

This is the single biggest problem I have with VSCode. It makes it feel... amateurish. It is infuriating and leads to confusing issues with trying save over a file that has changed with the "other editor". VisualStudio handles it fine yeah? Try heading over the corridor and talk to them about it.

[Gruntfuggly]

To be fair, Visual Studio isn't (quite as) cross platform...

[tommitytom]

To be fair, Visual Studio isn't (quite as) cross platform...

https://visualstudio.microsoft.com/vs/mac/

[Gruntfuggly]

That's why I said "quite". VSCode uses Electron and the node ecosystem which covers Windows, OSX and Linux.

[bpasero]

Small update from our side: this milestone a few changes got pushed that should improve the situation specifically for files that use different casing on operating systems that have case-insensitive behaviour (Windows, macOS).

For example, opening a file /some/path/file.css and /some/path/FILE.css would result in just 1 editor opening. Internally we introduced the notion of "canonical" URIs, meaning that the first time a file is opened, we take the casing for granted and anytime a different case is opened, we use the first one.

We currently do NOT have plans to support other forms of file paths, such as:

• symbolic links
• Windows 8.3 filenames (e.g. textfi~1.txt)
• Windows subst drive letters

That means, in these cases you would still see 2 editors opening with different models each, even though it is the same file on disk. But the majority of issues seems to originate from casing differences.

We are closing down for our May release with the changes included and monitor regressions which may require us to rethink the approach. But if everything goes well, this change should be available in stable early June.

You can already benefit from this change if you switch to our insiders build (https://code.visualstudio.com/insiders) and we welcome feedback.

[bpasero]

This completed for June via #93368, closing. In our current 1.46.x stable release you should already see a single editor opening if the case of the file path differs on Windows and macOS.

[damyanp]

Thank you! Great to see this addressed!

[benlesh]

@bpasero FYI: I'm in version 1.46.1 on Windows, I'm I'm seeing this issue.

I created a file named wampBroker.ts, realized it should be renamed to WampBroker.ts, and renamed it through VS Code's file explorer on the left. The actual file was renamed to WampBroker.ts, it shows up in the explorer that way, but the tab is still showing wampBroker.ts. I tried shutting down Code and restarting, I even tried renaming it to blah.ts and then changing it to WampBroker.ts, but as long as it's named WampBroker.ts, it shows in the tab as wampBroker.ts. It's a minor annoyance at best, but the bug still seems to be there. Not sure what cache to clear to fix it.

[benlesh]

Update: I figured out that (in Windows at least), if you wipe out the state.vscdb file under C:\Users\<user>\AppData\Roaming\Code\User\workspaceStorage\<find_the_right_directory> it resolves the issue the next time you open the workspace.

The easiest way to find <find_the_right_directory> was to open the workspace in question and then close VSCode, then sort the workspaceStorage directory by Date modified.

And I didn't "wipe them out", instead, I just renamed them to have the extension .old just in case anything was majorly broken.

I'm not saying I recommend this hack, but it did work for me. 🤷‍♂️

[bpasero]

The issue that renaming files to same path but different case is not reflected in the editor should be fixed with our upcoming 1.47 release. As usual, I highly recommend to install our insiders version that get's updated nightly and never worry about issues anymore because they get fixed asap.

You can give our preview releases a try from: https://code.visualstudio.com/insiders/