Ho to reproduce: 1. open some folder with couple mp3 files (I testes with 1 and 2). 2. Click "Find" 3. Select "Filename" and "From here" 4. Put in edit box any letter. I put "s" or "x" or letter on which starts any file name in opened folder. In result the list becomes empty. Wired, because it happens even I put first letter on which starts any file name in opened folder. I remove letter put before (or just clear edit box) and still the content (list view) is empty. Described result is independent on type of view. After I close "Find" the list view is restored.
Can't reproduce on my system. The find panel uses information from Baloo, so it's likely Baloo is messed up on your machine. You might try some of the things outlined here: https://community.kde.org/Baloo/Debugging
In my both systems where I tested this function "baloo_file" was working. I wasn't aware that Baloo supports this search. Maybe I tried to find it too quickly, after I copy files to test folder, so Baloo DB wasn't updated yet. I run "$ balooctl check", waited some time and checked the result in "Dolphin -> Find" this time file has been found, but when I cleaned edit box then list view has not been restored to original content as I expected. I wanted to find different file, and after first search I didn't get original list. Does in your system this view is restored when you clean edit box after search?
I have many and various problems like this with Baloo. It mostly works but with many corner cases and quirks. I have many text files that Dolphin Find by Filename won't find when I choose type "Any", but which *do* show up if I choose type "Documents". So try different type restrictions. Dolphin Find by Filename works oddly if you enter a single letter. It will return no or few files when you type one letter, but as you type more it will return a lot. E.g. if I type 'o' it returns 3 files TABLES_O.FW3, NEW_VS_O.DIF, and BYK8KO~O.PDF, but if I type 'or' it returns 4 Folders and 62 Files with names like CCMAIL.ORG, oracover.doc, etc. So at first it seems to be looking for an exact match with the letter 'o' on its own, treating the filename as a set of words ("TABLES" and "O" and "FW3"), but then it switches to do a partial match. But it's still matching from the start of "words" in filenames, e.g. typing 'mai' won't find CCMAIL.txt but will find SPAGE_MAIL.txt The behavior is undocumented and non-obvious. It would be great if someone knowledgeable wrote an explanation of Dolphin's find by Filename. In reply to Nate Graham from comment #1) > The find panel uses information from Baloo, so > it's likely Baloo is messed up on your machine. You might try some of the > things outlined here: https://community.kde.org/Baloo/Debugging How can you simulate Dolphin's Find by Filename from the command line? baloosearch doesn't have a filename switch. https://community.kde.org/Baloo/Debugging doesn't say anything about how Dolphin's Find by Filename works. `balooshow -x /path/to/γένεος_baloo_test.txt` has a line File Name Terms: Fbaloo Ftest Ftxt Fγενεος baloo test txt γενεος and I think if you type more than one character in Dolphin's find by Filename, it does a match against these terms anchored at the start. Or something like that... ^If these sentences are correct I can add them to KDE Community Wiki somewhere.
From my side I can add next bugs/drawbacks. 1. baloo doesn't search in directory which is symbolic link to another directory. Please note. This item isn't present on list "Do not search in these locations" 2. When I type some string in KRunner then baloo returns (in combobox of KRunner) not existing files, so those which have been removed some time ago from local disk. I wonder why index isn't automatically updated from time to time. Or isn't possible periodically schedule of recreation the index. I wasn't able to find proper options in "File Search - System Settings Module". Tested with KF-5-47, Qt-5.11.1, Plasma 5.13.1
(In reply to skierpage from comment #3) > ... It will > return no or few files when you type one letter, but as you type more it > will return a lot ... Yes. Seems to be the case, there's an exploration of the issue under the third comment in Bug 434589 (In reply to Piotr Mierzwinski from comment #4) > ... baloo doesn't search in directory which is symbolic link to another > directory ... Agreed. Or "baloo doesn't follow symbolic links" to discover extra directories t index. Thae rationale is that baloo relies on a one-to-one mapping between full filenames and its internal ID (based on device and inode). Anything that means that one file might appear on more than one path is dodgy... You can include the target directory in the "include list", as under Bug 435389 (13th comment), but read the "Don't do that" in the 14th Comment :-) > ... those which have been removed some time ago > from local disk. I wonder why index isn't automatically updated from time to > time ... There's some more work required on clearing up the entries after files have been deleted. Bug 353874
(In reply to tagwerk19 from comment #5) > ... as under Bug 435389 (13th comment) ... Oh no it isn't... .. it's Bug 435383 (13th comment) I think this means don't do this if the symlink goes to somewhere you are already indexing.
What's the state on this now? I don't think Dolphin's behaviour has changed a lot - you do still have to be careful and make sure you know if you are asking for a filename or a content search, you sometimes have to refresh Dolphin's search results page as it can show cached results and you generally need to type two or three characters before you see results. I think skierpage's summary in Comment 3 is still correct: Baloo returns any exact matches it has if you do a single character search, not treating the query as an "o*", but a for two characters a search for "or" or treated as a search for "or*". This is for filenames, for content searches if you type one or two characters you get the exact matches, you need to type 3 characters before you get a search for "org*"