Case-sensitive filesystems are treated insensitively

[DanTup]

I'm trying to figure out how best to handle #121106, but while testing on a case-sensitive file-system I noticed that VS Code is treating it insensitively. Here I created two files differing only in case, but VS Code only shows one, and when I try to open the second one, VS Code instead just shows the first (the content here says lowercase but the tab shows FOO.DART, yet FOO.DART contains UPPERCASE:

If VS Code is going to treat all filesystems as case-insensitive, that would also simplify things for language extensions, but my understanding from #121106 is that the filesystems behaviour should be honoured. It's important that language servers know how the client will behave (and in the case of LSP that clients behave the same, or announce their behaviour).

[bpasero]

We don't support case sensitive macOS: #94307

[DanTup]

@bpasero is there any way for me to understand what the rules are here for all platforms? For example on Windows and Linux does VS Code also assume all file-systems behave one way, or does it handle case-sensitivity based on the specific volumes there?

Thanks!

[bpasero]

@DanTup check how our local native file system provider only adds the path case sensitive capability on Linux here:

vscode/src/vs/platform/files/node/diskFileSystemProvider.ts

Lines 61 to 76 in c554dcc

	get capabilities(): FileSystemProviderCapabilities {
	if (!this._capabilities) {
	this._capabilities =
	FileSystemProviderCapabilities.FileReadWrite |
	FileSystemProviderCapabilities.FileOpenReadWriteClose |
	FileSystemProviderCapabilities.FileReadStream |
	FileSystemProviderCapabilities.FileFolderCopy |
	FileSystemProviderCapabilities.FileWriteUnlock;
	if (isLinux) {
	this._capabilities |= FileSystemProviderCapabilities.PathCaseSensitive;
	}
	}
	return this._capabilities;
	}

When you are connected to a remote (SSH, Docker, WSL), we respect the target OS in the same way.

tl;dr: only Linux is considered path case sensitive for VSCode (either local or remote).

[DanTup]

@bpasero thanks! I just found something similar here:

vscode/src/vs/workbench/test/browser/api/extHostConfiguration.test.ts

Line 33 in fd52949

return new ExtHostWorkspace(new TestRPCProtocol(), new class extends mock<IExtHostInitDataService>() { }, new class extends mock<IExtHostFileSystemInfo>() { override getCapabilities() { return isLinux ? FileSystemProviderCapabilities.PathCaseSensitive : undefined; } }, new NullLogService());

only Linux is considered path case sensitive for VSCode (either local or remote)

To clarify - this means where the extension host is running, right? So on Windows WSL, it would be considered Linux and sensitive?

Thanks!

--

Edit: I re-read, and that looks to be the case. Thanks!

[bpasero]

Yeah thats right. And for any other file system provider we respect whatever is used for isCaseSensitive when registering the provider:

vscode/src/vs/vscode.d.ts

Line 10717 in e1a0176

export function registerFileSystemProvider(scheme: string, provider: FileSystemProvider, options?: { readonly isCaseSensitive?: boolean, readonly isReadonly?: boolean }): Disposable;

[DanTup]

Got it - thanks! (I think that flag might not be available to LSP servers, although I suspect most do not currently support non-file:// URIs so maybe not a big issue).

Is this likely something that will be improved in the future? It seems like right now a language server will need to decide between doing what VS Code is doing, or doing what the underlying filesystem says (both of which will likely have some edge cases that may have issues).

Thanks!

[bpasero]

It seems like right now a language server will need to decide between doing what VS Code is doing, or doing what the underlying filesystem says

Is this specifically for macOS that is configured to be case sensitive?

[DanTup]

@bpasero the original issue I need to fix shows up for macOS case-insensitive too (#121106), though it's not strictly caused by this (it's caused by VS Code telling us a file was renamed, but then sending events using its old casing). Fixing this is going to require changes in the language server (eg. to resolve all incoming paths to their underlying filesystem case, rather than assuming the one from VS Code is correct) so I want to make sure I fully understand the rules before making changes (to avoid potentially introducing other issues because we normalised paths somewhere VS Code was treating them as case-sensitive even if the filesystem did not).

[bpasero]

I think we have so far stayed away from supporting case sensitivity on macOS simply because back in the days it seemed not recommended to run with given a lot of apps assume different (not sure that changed lately). Unless there is overwhelming ask from the community I do not think we would tackle that anytime soon.

[DanTup]

This affects Windows and Linux too - both of them support both types of filesystems. I don't know if they're common or fraught with danger though (although I'll note I do use USB sticks and external drives across platforms, so I guess at least at some times I'm using filesystems that wouldn't match VS Code's behaviour).

Probably it makes sense for the language server to use the underlying filesystem, otherwise it may introduce bugs for non-VS Code users. The number of affected users is probably fairly small (and if they do hit issues, it's more understandable given VS Code's behaviour than it would be in a non-VS Code editor that's behaving as expected).

Thanks for the info!