Sublime Forum

ST4 "Find in Files" not searching all subfolders

#1

Windows / Fresh ST4 install / fresh data directory

Not getting results from files in ‘most’ project subfolderse.
‘some’ folders are returning results though.
Cannot find the reason causing the ones not being hit recursively.

Notes/Actions:

  • was not an issue in ST3.
  • tried gitignore option on/off
  • affected dirs not included in gitignore
  • affected dirs not included in binary_file_patterns or index_exclude_patterns (or any settings)
  • affected files (in subdirs) ‘are’ indexed and found in other plcaes (definitons, autocomplete, etc)
  • tried turning Use Buffer on/off
  • it does find stuff if I specifically put a subfolder path into the “where” field, just not when searching everywhere.
  • full (read/write) permissions on all folders
  • tried creating new project from scratch in different ways
    (add folder via File menu, then save project)
    (“add folder to project”, then save project)
  • tried defining explicit path in .sublime-project file
  • tried new workspace

Thanks for the help!
-Drew

0 Likes
#2

Are those folders perhaps ignored by git and thus the new “Follow gitignore” option in the find dialog is causing it to skip those.

2 Likes
#3

No, as mentioned I tried toggling that option off. but also they aren’t ignored in git anyway.

If this helps… created new subfolders to test this problem and files in them are not coming up in results either.

I’m pretty stumped by this and it’s a feature I use all the time so hope someone knows what’s up.

0 Likes
#4

Does it happen in safe mode?

0 Likes
#5

yes, still doesn’t work in safe mode :\

0 Likes
#6

With the gitignore setting turned off I don’t see any way we’re ignoring directories other than the explicit exclude/include rules in the “Where” field. Are those directories perhaps symlinks or some other kind of special path?

0 Likes
#7

Chiming in here to say that I’m seeing the same behavior. I have a sublime project setup that contains 325+ git repos (of Java projects). They are all the projects I maintain for my team and I often have to search through the entire codebase. Discovered late last week that a fair number of the projects were not indexing their /src/test/java folders. Expanding the tree on the left sidebar showed that /src/test/java folder as not navigable and with a chain link on the icon. Looking at the Console output it says that “XYZ/src/test/java skipped because it was already found as XYZ/src/main/java” (or something to that effect).

EDIT: I guess I should make it more clear that the 325+ repos don’t really matter as I can recreate this by opening just a single of those repos in Sublime Text.

For those repos that exhibit this issue I can open the exact same repo, exact same folder in Sublime Text 3 and all files - /src/test/java included - are indexed (meaning they are navigable in the sidebar and searchable). I even cloned a new copy of the repo into a completely separate directory and was able to recreate the issue. I spent a little bit of time trying to create a new repo that would reproduce the issue that I could share here as I cannot share my company’s repos publicly but I only spent an hour on that and wasn’t able to recreate it.

For now, sadly my solution was to completely uninstall ST4 and re-install ST3. I will have to use ST3 until I have the resources (ha) and/or time (double-ha) to devote to more investigation.

If there’s any other information I can provide I’m happy to. I’m using Windows 10 Enterprise, Version 2004, OS build 19041.985. And I was using the latest (newest) Sublime Text 4 version. I’m now back to ST 3.2.2, Build 3211.

0 Likes
#8

I’m just as confused as you are, which is why I reached out.

  • Nothing in the “where” clause (except the default descriptive text of “open files and folders” (I mean, this actually means “all files and folders” right?)
  • No symlinks or unique paths
0 Likes
#9

Through trial and error, here is a strange conclusion:

Any folder–new or old–named/renamed to something that alphabetically comes before/= “data” (i.e. apple, banana, config, damn_confusing, data) IS searchable. For example, “plugins” was not searchable, but if I rename it to a1_plugins it becomes searchable.

“data” happens to be one of my directories, which is why I reached that point in the testing cutoff point. It’s possible other people’s projects have a different “alphabetical cutoff point”? :man_shrugging:

note, this only applies to folder names, not file names. All files in root or inside a searchable folder return results.

There are no rules anywhere (git or sublime) pertaining to this behavior/exclusion, so…conclusions?

Thanks,
Drew

0 Likes
#10

I’m unable to reproduce this as described.

Screenshot%20from%202021-06-21%2016-09-31
Screenshot from 2021-06-21 16-09-31.png923×428 25.1 KB

1 Like
#11

Thank you for testing that out. You led me to discovering that this is a unique problem to my project and ST4. As it happens, it is my data directory causing the search to stall when it reaches it in a top-down recursion.

Therefore, adding it to binary_file_patterns is an adequate solution, and I can just search it directly as needed.

Thanks!

1 Like
#12

Thank you for this hint.
I’m quite disappointed that this is the new default for the Find in files - never noticed it before but caused a lot of confusion today.
Please deactivate it by default in the next version.

0 Likes