Glob matching should be case insensitive

[fpintos]

• VSCode Version: 1.4.0
• OS Version: Win10 1511

Steps to Reproduce:

1. using VSCode, open a directory stored in an NTFS volume, which has files named FooContainer.cs
2. press CTRL+SHIFT+F to invoke Find in Files
3. press "..." to show 'files to include'
4. enter "*_/_container.cs"
5. search for something that is known to exist in the file.
6. results: nothing is found
7. replace 'files to include' with "*_/_Container.cs" (only change is the upper case C instead of lower case)
8. search again, this time results are found as expected.

Since Windows NTFS is not a case-sensitive file system, the expected results is that I can search in files using any case in the 'files to include'/'files to exclude'.

[bpasero]

Changing this will be a regression for people that expect this behaviour, so if we ever want to change this it needs to be behind an option. It would be nicer if in the glob pattern itself you could define if it should match case sensitive or not (similar to how this is possible in RegExp).

[eamodio]

Yeah, it would be great if there was an option (button) to toggle the case-sensitivity on the glob patterns

[roblourens]

I imagine them remaining case-sensitive by default, and being able to add

"search.exclude": { "Foo/**": { caseInsensitive: true } }.

And in the search viewlet, either there's a button in the include/exclude boxes to set case sensitivity or a setting. Maybe this is all overkill, I don't know. It would be a lot easier to make all globs case-insensitive. I don't know how many people want to exclude FOO/ but not foo/.

[roblourens]

@bpasero Looking at this again, I think defining this per pattern is overkill. gitignore is case-insensitive. I doubt many people depend on case-sensitive patterns. I think one of these options would be simpler:

1. Make all patterns case-insensitive
2. Case-insensitive by default with a setting to make all case-sensitive
3. "smart case" where patterns are case-insensitive unless they contain a capital letter

Thoughts? This would apply to patterns in ripgrep and glob.ts. If it's an issue for internal use of glob.ts, it would be easy to keep an option there.

[bpasero]

Maybe we should turn this around and make all patterns case-insensitive unless you provide a separate option, e.g. "search.exclude": { "Foo/**": { caseSensitive: true } }?

[roblourens]

Sure, but is enabling it individually per glob worth it, vs something like a global setting?

[bpasero]

@roblourens actually given more thought on it, we cannot add this as option to the glob because e.g. in our extension API a glob pattern passes as simple string. The only way how we could support it generally was with some new syntax as part of the glob string (like the /i option for regex). Given that, a setting might be our only choice after all.

[rjamesnw]

This causes an issue with TypeScript. An already existing project I have has the file names with the class case, so User.ts for the User class. This becomes user.js after compiling and the glob breaks, so the pattern to hide TypeScript generated files (as stated on Microsoft’s own site: https://code.visualstudio.com/docs/languages/typescript) is bad advice for Windows users since this case sensitivity causes it to fail. This should never be the case on Windows where file names are not case sensitive.

[isidorn]

This feature request will not be considered in the next 6-12 months roadmap and as such will be closed to keep the number of issues we have to maintain actionable. Thanks for understanding and happy coding!

[bpasero]

Let's reopen, I think we did not conclude what to do here.

[alexsandrovp]

I think there should be an option in the API call:

instead of
vscode.workspace.findFiles(...stuff)

something like this:
vscode.workspace.findFiles({caseInsensitive: true}, ...stuff)

[piyushsoni]

Hi,
I'm surprised such a basic issue is open after 5 years! I was just bitten by this badly on macOS. The problem is not that the file inclusion/exclusion pattern in search is case sensitive - the bigger, much more severe problem is that you don't tell that to us! How about while you are discussing the best way to solve the problem (I read some of the comments above, still don't understand what's wrong in just giving an option in the Search settings with any default you like and be done with it) you at least write a hint text in the 'files to include' textbox that the file inclusion/exclusion will be case sensitive! Please understand the severity of this problem of not knowing this by default, especially when developers are coming from Windows to Linux/macOS and already trying to cope up with these unnecessary case-sensitiveness everywhere.

I hope a Hint-Text warning like this could be implemented without any problem and no one would mind it :

[EdLichtman]

Hi all, 6 years later, hoping for a fix for this. I've gotten used to knowing that I screwed up the casing, but it's still incredibly annoying. Hoping there may be a fix for it. My current workaround I just realized today is, since the words are generally easy to decipher, (for example, there may be something called RedactedTool), I can type in edactedool, but that's a really bad and inconvenient workaround when it takes me an hour to remember it.

Putting a watch on this issue.

@roblourens I'll reach out to you over email to see if I can eventually help with this issue. Never committed to VSCode, but I'd love to take a stab at this, if you have ideas for how it should be implemented.

[worksofliam]

Bump. Looking for case-insensitive searching via API.

[martinhoess]

Bump.
This annoys me almost every day and has also led to " strange" problems because something was forgotten. Every other search in the VSCode is not case sensitive (or can be switched), only this one is not.

[splatteredbits]

My suggestion is to add a button in the "files to include" and "files to exclude" fields, just like in the search field, that toggles case-sensitivity on/off. That way, users are in complete control and don't have to go find an option somewhere to turn it on and off. I think case-insensitivity is the best default because filenames are definitely not always consistently cased. In our case, we have Web.config and web.config files spread all over the place. So having a default case-sensitive search causes problem. I think most people, regardless of file system, expect a case-insensitive filename search by default.

Screenshot of suggestion:

[grantx2016]

It would be wonderful if this could be fixed by some smart person out there. It's not like it was only just discovered. I have wasted hours trying to figure out why my search was including files that were explicitly excluded in the glob pattern, and now discovered there is no way to make it case insensitive. Perplexed. Bugs like this should be fixed before new features, IMO.

[bpasero]

Hacked something here: f89dc7b

I thought I would use it, but then decided otherwise. Anyway, sharing since its provides the foundation (I think) but lacks tests.

[zabcik]

This is pretty annoying. :-(
May search analysis get wrong. Because no-commented case sensitivity in "files to include".
I like solution proposal by @splatteredbits - add control to case sensitivity.

Today's work-around is a bit crazy.
".[Pp]ermission[Ss]et.al" covers ".PermissionSet.al", ".permissionset.al", etc., but not ".PermissionSet.AL".

Please, fix search feature.

[RandScullard]

I just got burned by this. I couldn't figure out why my search with "files to include" wasn't working. I even checked the docs to see if there was some quirk to VSCode's glob syntax. It never occurred to me that the glob would be case sensitive, and the docs don't make any mention of it.

Since this issue has already been open for seven years, could someone at least update the documentation to highlight this behavior and maybe save someone else from wasting a bunch of time?

[zabcik]

Dear @roblourens, @bpasero, @chrmarti,

I hope this message finds you well.

I would like to draw attention to a longstanding issue that has remained open for seven years or propose an update to the documentation. In the file glob.tx, within the function parseRegExp [link provided: https://github.com/microsoft/vscode/blob/745cb554226a331891e47e5bf3901eeb7a770760/src/vs/base/common/glob.ts#L112], it appears that there might be a case sensitivity problem on Windows systems.

Considering that Windows typically operates with a case-insensitive file system, I suggest exploring whether applying the regular expression switch for case insensitivity, "/i", might offer a potential resolution. This change could potentially be a few-line fix.

Could you kindly review this suggestion and provide feedback on its viability or any alternative solutions?

Thank you in advance for your attention to this matter.

Best regards,
Tomas

[RalfReddings]

Please fix this issue. I ended up forgetting about this little issue and wasted 40 minutes until I had to searh for this issue report all over again.

[Thaina]

At least for setting, Could we just have new setting for the new version of vscode and leave the old setting as old behaviour?

I would like to also suggest that files.exclude and search.exclude could be revised into new setting that define case-insensitive glob pattern and also specified a string as specific setting in addition to true/false

Such as

{
    "exclude": {
        "**/*.fbx": true, // FBX / fbx / fBx / Fbx
        "library/": true, // Library / LIBRARY / library
        "UserSettings/": true, // UserSettings / userSettings / usersettings / Usersettings
        "**/*.meta": "file", // exclude from file but still in searchable, same behaviour as set true but "search.exclude" as false
        "**/*.jpg": "search", // opposite of above case
    }
}

Eventually the old setting could be deprecated. I don't think people should rely on case sensitive glob for directory

[dperez83]

Unbelievable I lost some time figuring out a file was skipped because the search is case sensitive. Please fix it. Thank you

[zabcik]

Hello @andreamah,

I see that you are assigned to this issue. Could you please provide a brief status update?

Thank you.

[andreamah]

Hi! Unfortunately, this currently is not priority to be fixed by the team. :( I am aware of it and will try to fix it once I have some extra time.

[zabcik]

Thanks for letting me know.

[berot3]

i see we got someone new to help with our cause :) welcome @osortega and thanks @rebornix !