Incorrect URI casing passed to extensions on Windows after file rename

[Colengms]

Version: 1.62.2 (user setup)
Commit: 3a6960b
Date: 2021-11-11T20:56:38.428Z
Electron: 13.5.2
Chrome: 91.0.4472.164
Node.js: 14.16.0
V8: 9.1.269.39-electron.0
OS: Windows_NT x64 10.0.22000

On Linux, I'm seeing that a file gets a didClose/didOpen when renamed while open. On Windows, if the rename only alters the casing of the filename, no new didClose/didOpen occurs. VS Code will continue to refer to the file using the old casing. If the workspace is reloaded with the file still open, the new session continues to refer to the file using the old casing.

Our extension (C/C++) relies on VS Code referring to the same file consistently with the same URI, and that URI matching the actual case of the file in the file system. We may need to match paths not received from VS Code, with URIs received from VS Code. We can work around the issue by always going to disk to detect the file system casing before doing any comparison against a URI received from VS Code. Though, I suspect this scenario is a bug and the intention is for VS Code URI's to refer to files consistently with casing that matches the file system.

A potential fix would be to issue didClose/didOpen for files on Windows even if only casing was changed.

[DanTup]

There's some related discussions about this in #121106 and microsoft/language-server-protocol#1203 (and microsoft/language-server-protocol#1263).

[jrieken]

@bpasero Are you saying that you do close and reopen the file (editor model) on windows and the API and/or LSP integration looses that somewhere further down?

[bpasero]

@jrieken no, there is no update to text models when the URI changes ever since you introduced canonical URIs. Since I cannot update the URI of a text model (without disposing and recreating it), there is a label update and an update to the "preferred" URI of my workbench model. I think the ask here is to transport that "preferred" URI to extensions.

[jrieken]

I think the ask here is to transport that "preferred" URI to extensions.

I am not seeing that being asked for but I take it as your proposal to tackle this. Tho, it would mean we have TextDocument#alternativeUris: Uri[] and I am unsure that helps to reduce confusion.

@Colengms Our point of view is that we do not "normalize" paths on case-insensitive file systems but that the first appearance of a URI defines its "canonical" form. Doing the normalization would be too expensive for us, think of an extension that delivers thousands of diagnostics or references. Our promise is that the uris of text document do not change and that "lookup function", like getDiagnostics honor different case strategies.

[DanTup]

Since it caught me out, it may be worth noting that VS Code is using the platform to decide if a filesystem is case-sensitive rather than the actual filesystem (see #123660). This can result in some weird issues if your filesystem sensitivity doesn't match the assumed default.

[Colengms]

Hi @jrieken . We may read file paths from the file system that we then need to deliver to VS Code as URIs. For example, a ReferenceProvider will return Locations containing URIs, some of those URIs may refer to files that are currently open (with different casing). (Or, RenameProvider, WorkspaceSymbolProvider, DefinitionProvider, DeclarationProvider, or the LSP equivalents). If we deliver a URI to VS Code that does not match the casing it's using for an open file, is VS Code going to correctly match it?

[jrieken]

If we deliver a URI to VS Code that does not match the casing it's using for an open file, is VS Code going to correctly match it?

Yes, that's our promise. The first usage/opening of an uri defines its canonical form. Then subsequent usages will be using the canonical form as well. Eg. the editor shows file:///c:/foo/a.c and a language service returns two references like so: file:///c:/FOO/A.c and file:///c:/FOO/B.c. The first will be referring to file:///c:/foo/a.c but the latter is kept (granted it is the first usage). If later someone opens file:///c:/foo/b.c it will opened as file:///c:/FOO/B.c

[dbaeumer]

I had similar issue in the ESLint extension and they only occurred when I passed URIs to other libraries (in my case ESLint). As long it only was inside my code VS Code's model of keeping one canonical form of an URI stable works for me.

For passing URIs to ESLint I found out that they use the disk representation as their canonical form. So before passing it on I do a fs.realpath and use the new path if only the casing has changed (real path does some symbolic link / subst resolving as well which you might not to see happening)