No files were found to search in

I recently upgraded from Windows 7 to Linux (popOS). After installing Komodo IDE on the new system, it appears to work well, except that I can no longer search in files.

Here’s what I used to do in Windows…

  1. Select a folder in the file list.
  2. Press Ctrl + S to open up the search bar to search within that folder
  3. Type the text I want to find in the “Find” box.
  4. Click “Find All” - and it would work for several minutes before coming back with a list of files where the particular phrase was mentioned.

Now, it doesn’t appear to search at all - simply returns “No files were found to search in.” every time.

I’m uploading a screenshot so you can see if I just selected something wrong… I have “search subdirectories” and “ignore case” both checked. Any advice is appreciated - thanks!

EDIT: I am using Komodo IDE 11.1.0, build 91033, platform linux-x86_64. Built on Wed May 30 10:04:58 2018.

It’s not obvious to me that anything is wrong assuming there are files in public_html. I have to assume the worst case scenario since i know nothing else, so can you do and ls in terminal in your public_html folder and confirm the things your thing should be there are there?

Is publich_html a symlinked folder? It should break things but perhaps it is and there is a bug in Komodo.

  • Carey

Hello Carey, thanks for your reply.

Yes, when I run ls in my terminal from the above directory I get a list of files in the project.

Here is the tail of that; files are indeed present in the folder.

typel@sys77:~/test-project/public-html$ ls -alh
 ...
-rw-rw-r--  1 typel typel 7.9K Jul 10 15:50  wp-mail.php
-rw-rw-r--  1 typel typel  17K Jul 10 15:50  wp-new-login-setup.php
-rw-rw-r--  1 typel typel  413 Jul 10 15:50  wp-pass.php
-rw-rw-r--  1 typel typel  334 Jul 10 15:50  wp-register.php
-rw-rw-r--  1 typel typel  16K Jul 10 15:50  wp-settings.php
-rw-rw-r--  1 typel typel  30K Jul 10 15:50  wp-signup.php
-rw-rw-r--  1 typel typel 4.6K Jul 10 15:50  wp-trackback.php
-rw-rw-r--  1 typel typel 3.0K Jul 10 15:50  xmlrpc.php
typel@sys77:~/test-project/public-html$

In this case, public-html is not a symbolic link - it is an actual folder.

I checked in Komodo’s pystderr.log file and found some strange warnings all over the place. It seems that perhaps the search options I’ve selected (such as search in sub-directories) are not actually taking effect. Is there any way to work around this?

[2018-07-12 14:14:21,452] [WARNING] prefs: The 'find-folders' preference has changed while the pref window was open. If you get this message, a pref panel is incorrectly modifying prefs and the modified value will be lost.
[2018-07-12 14:14:21,453] [WARNING] prefs: The '__all__' preference has changed while the pref window was open. If you get this message, a pref panel is incorrectly modifying prefs and the modified value will be lost.
[2018-07-12 14:14:21,454] [WARNING] prefs: The 'find-includeFiletypes' preference has changed while the pref window was open. If you get this message, a pref panel is incorrectly modifying prefs and the modified value will be lost.

EDIT: Then again, after restarting Komodo IDE, these errors have disappeared from the log and don’t seem to be returning, even if I toggle various search preferences on and off. Still doesn’t find any files to search… maybe it wasn’t related.

That’s really bizarre. Could you try Help menu > Troubleshooting > Restart in Safe-Mode then reproduce the issue?

Carey-

I just tried restarting in Safe-Mode. Interesting thing - in safe mode my Projects are not listed, so I just selected a random folder from the default folder list, hit CTRL+S and it was able to search through the files like normal.

Then I went ahead and created a test project in safe mode, selecting a particular folder and giving it a name (but not much else)… Then I selected the new project and tried to search one of its subfolders - and now it says “No files were found to search in.” again.

I’m thinking maybe that I’m missing a step when creating new Projects - maybe I’ve been doing it wrong all along but Windows was more forgiving? By chance, do you know of anything that I might be leaving out of a Project’s settings which would result in this behavior?

I’d need to know what you’re doing to know if you’re doing something wrong, ie. every click, input field, etc. It’s pretty straight forward though. If the folder you selected has content it’s really just add a name, select a folder, click create, click open. Let me know if you deviate from that and make sure you’re selecting Create and open at the end of the widget steps.

Can you look at Help menu > List key bindings and clarify what you have mapped to ctrl+s? That’s not a default key binding in Komodo so I’m not sure what you’ve set it to.

  • Carey

I finally found the cause. When creating new projects, I had been selecting one directory above the actual wwwroot to keep Komodo’s project configuration files out of the active directory. For example, if I had a project located at ~/Project1/wwwroot/ I would select ~/Project1 and then when the file list showed up I would immediately right click “wwwroot” from the list and click “Make This Folder Root”.

For some reason, doing things this way works fine in Windows, but breaks everything in Linux. I guess I’ll just have to get used to sharing my public root folders with Komodo. I hope it won’t open up any security holes if one of Komodo’s files inadvertently gets published to a live server. Doesn’t look like they contain anything sensitive…

1 Like

If you want to keep your project file out of the project root you can Right click the project in Komodo > Project Prefs > Project Prefs: Project Base Dir.

That’s odd this broke things so badly. You never told me what you have ctrl+s mapped to.

  • Carey

Carey-

I think I meant to say ctrl+f and not ctrl+s, my apologies. This is mapped to Find > Incremental Search … I didn’t modify these key bindings since the default installation.

Thanks for the tip, but when I changed the Base Directory in the Project’s Preferences, the Komodo files remain in the wwwroot folder as before, even after restarting Komodo. If I move them manually, Komodo can no longer find the files. I think the only way to get the files stored outside is during initial setup, but for some reason if you set it during that period, pathing gets thrown off.

At any rate, none of this is important anymore, so long as those files don’t contain any passwords or other sensitive information. I doubt they would get pushed up to a live server, but I’ve been in this long enough to understand that mistakes do happen.

Ahhh i missed the s on files. You’re talking about the .komodotools folder, correct? I thought you were talking about the .komodoproject file. .komodotools contains toolbox items. You’ll may have noted that when you open a project in Komodo, it also opens a toolbox folder/minitoolbox in the general toolbox. Note my mini project toolbox aus below.

So it’s up to you what’s in there. We don’t’ write anything to it with out you creating the item to be written from the toolbox items available.

Thanks for clarifying. And yes, you are correct, changing Base Directory will have no effect on where that folder is created. It’s always in the project root.

Thanks for your patience on this @Typel.

  • Carey

So eventually I found the true cause and thought I would update this thread just in case anybody is looking here for answers in the future.

What was happening is that I had named some of my project folders using brackets - ie, domain.com[test] and domain.com[live] … When I renamed them to domain.com.test and domain.com.live, I was able to recreate the projects in question and now they are completely searchable no matter where the komodo project files are stored.

I think the reason the problem had subsided when I set the initial base directory inside a subfolder is because it was one directory beneath the folder with brackets in the name and therefore didn’t encounter that problem when searching.

Anyways, just correcting the record. Thanks for your help!

@Typel, Thanks for correction. That makes way more sense.