leave home as not indexed then, i don’t think it matters, and just add the folders you want to index.
also you should not use the monitor command unless the status first shows that the indexer is running, otherwise it seems to throw errors.
You would be taken seriously, but we are already aware that the Dolphin search user experience is not good. It is a major topic of discussions.
You are not alone in wanting a search separate to Baloo to work as expected in Dolphin. There are plans and even work in progress (Draft: Overhaul search UI (!797) · Merge requests · System / Dolphin · GitLab) to allow users to easily switch to a non-Baloo search. The next Dolphin release will have changes to how the non-Baloo search works.
The Dolphin 24.12 release will use ripgrep-all (a search tool that does allow searching the content of .docx files rga: ripgrep, but also search in PDFs, E-Books, Office documents, zip, tar.gz, etc. - phiresky's blog) if that is installed on your system and Baloo is disabled for a location. See Use `ripgrep-all` / `ripgrep` to improve search in Dolphin - KDE Blogs for more background information.
I am aware of that, first I run enable, then check and then monitor, for this reason 
That is nice to hear. Regarding the search overhaul, instead of reinventing the wheel, shouldn’t they consider just copying Nemo or other file managers that do this well, unless they are planning to make it even better?
On the other hand, will Baloo be fixed as well? Specifically, removing of deleted/moved files from the index file instead of purging it every time?
Regarding .docx files, I will never understand this issue. It finds words in SOME .docx files but not others. In any case, I will probably wait for newer Dolphin releases, hopefully, this will get addressed.
Well, that is why the next Dolphin release will use an existing search tool i.e. ripgrep. We do not want to reinvent the wheel there, so we use existing technology. ripgrep is renowned for being one of the fastest search tools.
I have had bad experiences trying to collaborate with the previous maintainer of Baloo, so I no longer have high hopes for that project. But ultimately I neither know the current state of the project well, nor do I know what is going to happen with Baloo.
If ripgrep-all is able to find the file with the given content, the new Dolphin version should also be able to find it. One reason why the curent search might not work reliably could be that it does not understand the .docx file format and just parses it as plain text, which means it might get confused by formatting information while searching the contents.
Approximately, when should we expect ripgrep? Baloo seems to have destroyed all my basic intuition regarding how search would work. So, I indexed a folder called “Books” in my home directory. Searching a certain keyword from my home directory gives me 5 results. I move one level up. So I am on /home/ folder. Searching for the same keyword returns 1 result from a totally different folder. Looks like it doesn’t understand how subsets work…
Also, please tell me that ripgrep won’t require baloo
UPDATE: I used ripgrep-all tool through the terminal and it does find substrings just like Nemo. In fact, I got the same matches for my search, both in Nemo and Ripgrep-all.
I hope this is going to work through Dolphin GUI in the near future?
I’m not sure where this came from… although there might be an element of truth in it.
Baloo does notice when files are deleted and removes them from the index. It uses iNotify to watch folders and index files when they are changed and follow up when they are moved or deleted. Same for folders…
It seems to be slower are deleting files than indexing though. If you delete a large folder tree, you might be giving it a headache.
If you reboot before the clean up is done, you can be left with files that are not cleaned from the index. At least that used to be the case.
Note that Baloo does not remove files from the index just because it notices they are not there. They might be on devices mounted (and indexed) and at a later time not mounted. Keeping hold of the index information in this use case is sensible…
Try a “balooshow -x one-of-your.docx”
This should give the metadata and list of the “words found” in the file. Baloo depends on (I think) the kfilemetadata code to extract plain text from all the various sources.
A Microsoft .docx? Maybe there’s some playing “catch up” to be done…
I remember something like that…
I think there is but only for plain text files…
At this point, I am willing to wait for the integration of ripgrep-all. It functionled exactly like Nemo but it was faster. However, I thought just installing it would make it be integrated to Dolphin, which was not the case. It only works through terminal now.
I hope it is added to Dolphin sooner than later.
By the way, I don’t use Microsoft, the .docx file I created was made with OnlyOffice.
If you have a testfile where the indexing fails, open a bugs.kde.org issue and attach it.
It might be possible to pin down what’s happening…
We will release Dolphin 24.12 in December. From then on it depends on your distribution how long it will take for this update to be available for you. Since you are on Fedora, it should not take long then. Dolphin 24.12 will automatically integrate ripgrep-all and use it when it is installed. It will be used when Baloo is not indexing the folder you are searching in and you are doing a content search.
The problem is that those files are getting indexed
With ripgrep-all, would I even have any reason to use baloo in the first place? It searches everywhere, including the file content. Shouldn’t this basically retire Baloo?
Would need a bit of detective work…
Set up the indexing for just one folder, kill Baloo and purge. Run “balooctl monitor”, see if a plaintext file gets indexed. Copy the test .docx across and check to see what you get with “balooctl -x …”
Depends. You can do the work beforehand (indexing files as they are created/modified) or you can search through everything “as and when” you need to.
Indexing first will give you faster results, and it will be faster. At the cost of complexity of course…
I wonder if there is anything strange with the Fedora 41 implementation, Fedora indexes ~/Documents, ~/Music, ~/Pictures and ~/Videos by default, avoiding $HOME. I’ll have a look…
Does indexing have a noticeable impact on SSD health?
I don’t have so many files to the point that I have to wait hours to search for something. When I tried ripgrep-all to search something it gave me the exact same results as nemo in a very short time. I don’t think I’d be using Baloo if ripgrep-all is available. In any case, doesn’t ripgrep-all require baloo to be inactive for it to work? So, it does make Baloo obsolete then?
I feel like a substantial part of this thread hasn’t called out on the existing bugs, and those might be misunderstood as expected behavior.
- File contents search should work on DOCX just fine the way you’d expect on Nemo. If it doesn’t, it’s a bug, please report it (preferably with a reproducible file).
- You shouldn’t be getting a second entry for your home like that. It’s clearly a bug, please report it.
- See also: Baloo/Debugging - KDE Community Wiki
The new ripgrep backend will be cool and all, but it’s desirable for baloo to actually get those bugs fixed too.
Other functionality also depends on baloo, like the following off the top of my head:
- Dolphin’s tag support (I don’t know if it can done via ripgrep)
- Milou (the search widget you can add to the panel)
- KRunner’s search backend (also used for the menu and overview)
I think nowadays no, early ones I’d wonder about.
You might be running VMs on an SSD, or swapping to it. I’m not sure which I’d worry about more. All the same, keeping an eye on the SMART status is always wise.
Baloo is quite powerful as others have mentioned. It can give you a lot of control over searches (filename, metadata, xattr tags as well as content). Best intro is probably here:
https://www.reddit.com/r/kde/comments/pmcshj/tip_baloosearch_kioslave/