Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
bpasero opened this issue Sep 22, 2016 · 122 comments
Closed

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

bpasero opened this issue Sep 22, 2016 · 122 comments
Assignees
Labels
Milestone

Comments

@bpasero
Copy link
Member

@bpasero bpasero commented Sep 22, 2016

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:

@bpasero bpasero added the bug label Sep 22, 2016
@bpasero bpasero added this to the Backlog milestone Sep 22, 2016
@bpasero bpasero self-assigned this Sep 22, 2016
@bpasero bpasero changed the title Issues when using wrong path casing when starting Code Issues with mixed casing of file paths entering the workbench Jan 3, 2017
@bpasero bpasero changed the title Issues with mixed casing of file paths entering the workbench Issues with not case-normalizing file paths (macOS, Windows) Jan 3, 2017
@bpasero bpasero added the debt label Feb 4, 2017
@bpasero
Copy link
Member Author

@bpasero bpasero commented Feb 6, 2017

Pushed a fix for the broken file events on macOS.

@bpasero bpasero changed the title Issues with not case-normalizing file paths (macOS, Windows) Issues with not case/fragment-normalizing file paths (macOS, Windows) Feb 7, 2017
@BillDenton
Copy link

@BillDenton BillDenton commented Mar 2, 2017

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

@bpasero bpasero modified the milestones: March 2017, Backlog Mar 16, 2017
bpasero added a commit that referenced this issue Mar 16, 2017
@jameshartig
Copy link

@jameshartig jameshartig commented Mar 19, 2020

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
Copy link

@bja-ableton bja-ableton commented Apr 17, 2020

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
Copy link

@Gruntfuggly Gruntfuggly commented Apr 17, 2020

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

@tommitytom
Copy link

@tommitytom tommitytom commented Apr 18, 2020

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

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

@Gruntfuggly
Copy link

@Gruntfuggly Gruntfuggly commented Apr 18, 2020

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

@bpasero
Copy link
Member Author

@bpasero bpasero commented Jun 5, 2020

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 bpasero added this to the May 2020 milestone Jun 12, 2020
@bpasero bpasero added debt and removed under-discussion labels Jun 12, 2020
@bpasero bpasero modified the milestones: May 2020, June 2020 Jun 12, 2020
@bpasero
Copy link
Member Author

@bpasero bpasero commented Jun 12, 2020

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.

@bpasero bpasero closed this Jun 12, 2020
@damyanp
Copy link
Member

@damyanp damyanp commented Jun 12, 2020

Thank you! Great to see this addressed!

@benlesh
Copy link

@benlesh benlesh commented Jul 7, 2020

@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
Copy link

@benlesh benlesh commented Jul 7, 2020

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
Copy link
Member Author

@bpasero bpasero commented Jul 7, 2020

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/

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.