editor.document.uri return stale URI after file rename

[jeffb-sfdc]

Does this issue occur when all extensions are disabled?: Yes

• VS Code Version: 1.63.2
• OS Version: OSX 11.6.2

Steps to Reproduce:

1. create a file

2. Using either the Finder, or within VS Code itself, rename the file and change the case, but don't add or remove any extra characters. For example, rename "testfile.js" to "testFile.js"
   -> In the Explorer view, the file appears correctly

3. Restart VS Code and open the same project (just to make sure the change is picked up)

4. With the file open and in the active editor, run an extension and call editor.document.uri

Result: The original filename is returned (eg "testfile.js")
Expected: "testFile.js"

We publish an extension and we have some code which is failing because of this.

[bpasero]

Yeah, this works "as designed", even though maybe unexpected: once an editor is opened it defines the casing of the document URI it shows. If you rename the file case, the document URI does not change, only the "associated resource" so that the label can update. When we close and reopen VSCode, the editor is still there as it was originally opened with the casing from the beginning.

On top of that we cache normalized URIs per session, so even when you now close and reopen the editor, the old URI form will preserve. The only way out is to close the editor and restart.

This is hassle, but imho a lot less hassle compared to all the issues we were able to fix with this approach ("canonical URIs").

#137256 is related where an API is discussed that could provide extensions with the "associated URI".

Question: how do you use the editor.document.uri that it would be relevant how the casing is?

[jeffb-sfdc]

Hi @bpasero , thanks for the reply.

Yeah, this works "as designed", even though maybe unexpected

Not knowing your codebase, or historical issues, from my view it looks like a bug. If I start out with foobarbaz.js, and then rename it (either via VS Code or via the finder) to fooBarBaz.js and then restart VS Code, the files system (ls), the Finder, and VS Code displays each display fooBarBaz.js, yet editor.document.uri returns foobarbaz.js.

While I know of the issue and the work around, I suspect our customers won't, and so when our code fails due to the file paths not matching, they won't know to rename the file to something with different characters, and then rename back.

how do you use the editor.document.uri that it would be relevant how the casing is?

It's a little involved. Without going into all the details, we're using a library which gives us a list of files of a certain type. The filenames in the list match what's in the file system (so /{path-to-file}/fileName.ext). In our code, we're creating a Map<string, string> of the files, with the key being the path to the file. Later we do something along the lines of:

  public findMatch(uri: vscode.Uri): string {
    return this.files.get(uri.toString());
  }

uri is coming from editor.document.uri, and since foobarbaz.js doesn't match fooBarBaz.js, the function isn't returning a match.

If this is "as designed" I'll understand, but this seems like a bug, and is causing bugs in our extension and impacting our users.

[bpasero]

@jeffb-sfdc we obviously face the same challenge in VSCode internally because of the way how we handle file paths and have utilities that explicitly ignore casing on platforms that are case insensitive (Windows, macOS), e.g. ResourceMap:

vscode/src/vs/base/common/map.ts

Line 757 in a1541e9

export class ResourceMap<T> implements Map<URI, T> {

This is not just limited to file renames, a user may choose to open a folder from the command line with "wrong" casing, e.g. code <path to folder in upper case> and we preserve the case in the session. As such, every code we have that tries to compare paths is ignoring casing on Windows and Linux.

This expands to extensions as well: if the folder is opened all in upper case, extensions will also get the upper case path with every Uri they observe (editors, workspace folders).

#137256 (comment) is relevant where maybe an API is needed for extensions to use these utilities as well.

[vscode-triage-bot]

This issue has been closed automatically because it needs more information and has not had recent activity. See also our issue reporting guidelines.

Happy Coding!