I can reproduce, the issue is that a glob pattern like /Users/bpasero/Development/Microsoft/monaco/src/vs/base/test/node/**/* matches on /Users/bpasero/Development/Microsoft/monaco/src/vs/base/test/node as well as /Users/bpasero/Development/Microsoft/monaco/src/vs/base/test/nodestar

@Apoorva-GA I think a workaround would be to set pattern: ${folder.uri.fsPath}/*/**. The single * means at least one character while the ** can mean 0-N path segments. Can you try that?

I fear about breaking people if we change our glob star to require a path segment, since we have behaved like this from day one. I know that other glob libraries seem to treat ** as "at least one path segment must follow".

/cc @chrmarti @roblourens

.../node/**/* shouldn't match .../nodestar, it should at least require node as a separate path segment, like: .../node/star. I wouldn't expect a fix to this to cause much breakage since the faulty behavior is quite unexpected from what I see.

Unfortunately I have to close this "as designed" simply because it would break too many things in our code. To give one example: Our default files.exclude setting is this:

"files.exclude": {
    "**/.git": true,
    "**/.svn": true,
    "**/.hg": true,
    "**/CVS": true,
    "**/.DS_Store": true
  }

But the matching in the files explorer for example is always relative to the root (e.g. we will match ".git" onto "**/.git"). If we change ** to be required, a top level ".git" folder would no longer match. There seem to be more examples, e.g. our extension recommendation system matching on file extensions would also break.

@bpasero What I suggested wouldn't break these cases, maybe I misunderstood your example from earlier?

@chrmarti so then maybe try to explain how "**" should behave? To give an example, the Python library implements **/*.js in a way that it will not match on something.js when I tested from the CLI.

@bpasero I agree it should match zero or more path segments. But node/**/*.js shouldn't match node_modules/foo.js nor node_modules/bar/baz.js, it should only match with node as a path segment and not with node as a prefix of a path segment. You said the current behavior is to match in that case in #41724 (comment).

@chrmarti I am having a hard time to encode that logic, nor understanding it. I find it hard to understand how a leading ** can be 0 paths (so that **/*.js matches on some.js) but an embedded usage such as node/**/*.js would not match node/some.js.

Btw if we were to change it, we would also need at the trivias we added for avoiding the RegExp, we seem to hit that case too with these patterns.

@bpasero I agree, what I'm saying is: node/**/*.js should match node/some.js, but not node_modules/some.js.

Good point 👍

I think I found a fix. In the parsing code (here) we typically add a path separator regex to the segments, but not if the next segment is a "**" pattern. I am still not brave enough to always require a path separator, but the fix is to require it if there are more segments to follow.

To verify: you can use the files.exclude setting in the explorer and have 2 folders (on the same level) where one folder is the substring of another folder and then e.g. exclude all JS of the one folder with a pattern like **/folder/**/*.js and verify that only the JS files in the one folder are hidden, not in the other.

@bpasero the workaround you suggested worked for me, but looks like this is fixed now.

Can I know in which insider version the fix is available?

@Apoorva-GA fix will be in todays insider build, let me know if it works for you.

@bpasero It works for me 👍
Thanks for the fix.