Case-sensitivity and file system providers

[jrieken]

Today we seems to have hardcoded logic to know when paths should be compared case-sensitive or not, e.g. callers of isEqualOrParent or isEqual and likely many more...

With b0ede6c I have added a file system provider flag/capability to signal that it is case-sensitive (default is case-insensitive). We need to come up with a strategy to communicate that information to consumers, e.g. the explorer or file events so that we do the correct thing.

A sample of failure is part of the memos-sample which creates to files that only differ in casing: https://github.com/Microsoft/vscode-extension-samples/blob/58ea8617190ee5566e001b9875b8b2c25a983857/fsprovider-sample/src/extension.ts#L30

[bpasero]

I guess we would need some service that can compare resources which has all the knowledge of the capabilities of the file system. Possible inputs to this service are the capabilities of the remote file system, and then for file://, the OS and possibly smarter things like having a real understanding of the file system. As a first step we could have a stupid logic in the service for file:// where we simply assume Linux is case-sensitive and the others are not.

[isidorn]

Introducing such a service makes sense but could it also be a part of the FileService?
I could look into adding this once we decide where this should belong. And I like the idea of starting with stupid logic which respects what we currently have.

[jrieken]

Introducing such a service makes sense but could it also be a part of the FileService?

👍 for adding this to the FileService, it is somewhat similar to canHandleResource

[bpasero]

We can start adding it there. The challenge will be to get access to this service from all places where we need to compare URIs. Also, I guess comparing 2 resources with different schemes should not be supported at all.

[isidorn]

Assigning to May so we investigate next milestone.

[jrieken]

Also, I guess comparing 2 resources with different schemes should not be supported at all.

Well, not supported as they are inequal by definition. So, compare scheme, then authority (both always case-insensitive according to my knowledge), and then compare path (case-sensitive or not) and optionally compare query and ignore fragment.

[isidorn]

We were focused on grid this milestone, next week I am on vacation, this is not for endgame -> June

[isidorn]

I plan to start investigating into this tomorrow by:

• updating the IFileService to have areEqual(first: uri, second: uri): boolean
• Implementing this in our FileService to simply respect the current platform
• adopt all the path comparisons to use the IFileService for comparison - it might happen that some clients of this will not have an instance of the IFileService as @bpasero pointer out - but we see

[jrieken]

Maybe a more portable Comparator would help, e.g. fileService.getUriComparator(): (a: URI, b: URI) => number. Once acquired we can pass the comparator around and use it in other places

[isidorn]

Did not have time this milestone -> July

[isidorn]

Does not seem like this will happen in the last couple days of the milestone (risky) -> september

[isidorn]

I have pushed the changes in the Explorer such that the Explorer will now respect the FileSystemProvider case sensitive capability. Explorer also reacts on the change of this capability.
I know that this does not solve all the issues, but should in theory help with many issues as @aeschli suggested.
So let's try it out with insiders from tomomrrow and for now closing this issue.