vscode: Files do not restore their preferred resource path casing when reloading window
- VSCode Version: 1.48.0-insider and 1.47.1
- OS Version: Darwin x64 18.7.0 / macOS 10.14.6
If I change the casing of a filename in vscode on macOS, the old file name casing is forever stored in ~/Library/Application Support/Code/workspaceStorage, this causes problems with extensions that require case-sensitive file paths
Steps to Reproduce:
- In vscode, create a file named EXAMPLE.txt
- Rename this file to Example.txt
- Right click on the filename in the top bar to see the case hasn’t changed everywhere in vscode
- Extensions that require case-sensitive file paths will no longer work for this file. This persists through restarts and cache clearing. The only way to restore functionality is by deleting the workspace storage file in
~/Library/Application Support/Code/workspaceStorage
This has come up when using the haxe language extension – after changing a file’s case, the old file case given by vscode is sent to the haxe compiler, breaking autocomplete for this file (haxe nightly build 4.2)
Does this issue occur when all extensions are disabled?: Technically Yes (but it’s probably not an issue without extensions)
About this issue
- Original URL
- State: closed
- Created 4 years ago
- Comments: 17 (14 by maintainers)
Commits related to this issue
- partially revert #102627 (data loss with hot exit) — committed to microsoft/vscode by bpasero 4 years ago
Very tricky, not having a good solution for now. The truth is that backup identifiers are the hash of a file path, so when an editor opens and gets dirty, the backup is a hash of its file path (preserving the casing). When the file is renamed, the hash does not change because we no longer change the underlying model, we just change the label.
If we now simply go ahead and change the model URI on restart because we pick the preferred URI now, the backup can no longer be found and the data is lost. Somehow the backup service would also need to be aware of a preferred URI vs initial URI.
The workaround for now is as I stated before:
Looks like the editor input serialised and restores the wrong uri
File editor inputs now keep track of their
preferredResource. This is the resource that was originally used by clients when wanting to create an input but it might be different from theresourcegiven our canonical form. However, when the file editor input is being recreated from storage, it will usepreferredResourceand thus has a chance of being created with the “correct” URI.This still requires a restart of VSCode but you no longer have to close the editor to get the “correct” URI.
This doesn’t make sense. The
codelens/cache2cache is to persist info about where code lenses have been so that you don’t see flicker after restarts or when changing files. However, is doesn’t define the path of the model so it cannot be cause such issues.