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.

[roblourens]

Yes, I still plan to do this, whenever I have time to update ripgrep.

I plan to make globs case-insensitive by default and add a setting to make them case-sensitive.

[roblourens]

Does this just affect files.exclude/search.exclude/search viewlet? Where should a setting go, to make it obvious that it impacts globs in all of these places? createFileSystemWatcher and findFiles from the extension host also take globs. There could be a case sensitivity option as part of the API, or it can follow the user setting.

WIP at https://github.com/Microsoft/vscode/pull/41214

[the-ress]

It would be great if at least the search sidebar had toggles like this:

[yuppox]

I just ran into this issue. Very annoying that user .php does not find UserProfile.php in "files to include". I have to use User .php.

This has been open for three years. Can we get a fix for it, please?

[tolgabalci]

Searched for dockerfile in "files to include" and only got partial results. Searched for Dockerfile and got the rest. This is a poor experience under Windows and there are no workarounds that can be used to search for all valid forms of a particular file.

Windows APIs and pretty much all Windows applications are case insensitive when handling filenames. VSCode is not properly conforming to this and should be fixed to avoid unexpected results and users who are mislead to believe they have seen all files, but instead have seen only a subset

[markdomansky]

Seems like this behavior should be OS specific or perhaps follow a model like regex. There are different ways but usually some suffix to the search string. Perhaps use something like \i for case-insensitive and \c for explicit case-sensitive searches.

[henrik-jensen]

@tolgabalci wrote:

... This is a poor experience under Windows and there are no workarounds that can be used to search for all valid forms of a particular file...

Of course there are workarounds: Look at this little beauty for the string "VeryLongFilePathThatGoesOnAndOnAndOn"

[Vv][Ee][Rr][Yy][Ll][Oo][Nn][Gg][Ff][Ii][Ll][Ee][Pp][Aa][Tt][Hh][Tt][Hh][Aa][Tt][Gg][Oo][Ee][Ss][Oo][Nn][Aa][Nn][Dd][Oo][Nn][Aa][Nn][Dd][Oo][Nn]

Or even better: 😏

{V,v}{E,e}{R,r}{Y,y}{L,l}{O,o}{N,n}{G,g}{F,f}{I,i}{L,l}{E,e}{P,p}{A,a}{T,t}{H,h}{T,t}{H,h}{A,a}{T,t}{G,g}{O,o}{E,e}{S,s}{O,o}{N,n}{A,a}{N,n}{D,d}{O,o}{N,n}{A,a}{N,n}{D,d}{O,o}{N,n}

🤪 /s

Ok, I ~essentially~ totally agree with you 😃

[henrik-jensen]

I would prefer a toggle option in the search gui for case, and not let it be determined by current OS or a settings entry, as sometimes on windows you do need case sensitive file path searches (e.g. when accessing a wsl filesystem from windows through wsl$ or even on a ntfs or fat32 LFN volume which actually does store the names case sensitive so why not use it) On windows case sensitive searches can help you discover crossplatform problematic include files.

[RamyRafik]

Not sure if this is related

118535 [Bug] Occurrence Highlight does not work in case of file path case mismatch

[AlGantori]

I just got bitten again by not seeing all the files !!! It's 2021, 5 years later, and this issue still OPEN

A note for those Case Sensitive Folks :)

1. Don't use, ever, any Casing Conventions, it means absolutely nothing. Case Conventions are only meant for those control freak in your enterprise team. Especially don't use cAmElCaSe it's the most stupid of all :)
2. Case Conventions are a personal choice, an extension in your IDE.
3. Don't use any case-sensitive languages eg. C, C++, C#, JAVA, JavaScript, TypeScript, CSS, XML, ... (I use them despite me)
4. Don't use any case-sensitive OS or FileSystem eg. Unix and all its flavors (I use them despite me)
5. When something is case sensitive I purposely use ALLCAPS just to see if I can blow some of its bolts off.
6. Semicolons, pure junk, don't even think twice toss them in the garbage.
7. Commas if you can't use them as terminators toss them out of the Windows

If an environment insists on commas and semicolons as separators I do the following:

[uglycoyote]

@AlGantori while I agree with you on some of your points, Please consider the possibility that the developers of VSCode who might have the power to improve this situation might also be some of the "Case Sensitive Folks" who are currently violating many of your proclamations. It is fair that you have opinions on this, but it comes off as a bit condescending when you tell everyone on this thread what not to do. It's also not very helpful that you are diverging into a completely different topic (with screenshots!).

[henrik-jensen]

@AlGantori : Oh yeah, those good old CP/M, DOS and BASIC days, those were times. /s Just a little reminder,- YOU FORGOT TO ALL UPPERCASE YOUR RANT POST 😄

[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: https://github.com/microsoft/vscode/commit/f89dc7baa9df0631069e1cedcb8232445720a466

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.