There are alternatives like fsearch that are blazing fast and they always find file/folders even if newly created.
Why can’t baloo change it’s underlying logic to make it better?
Seems like some bug.
Monitoring for new files on Linux is painful, either you add a billion inotify watches, scan periodically or use a privileged process so you can use fanotify (An update on fanotify [LWN.net])
I am not sure which method baloo uses at least not fanotify which should be the most reliable/reactive one.
That’s when indexing file content ? Does fsearch does it too ?
Because it takes a lot of IO to do regardless of the implementation.
Effort.
Contributor availability…
The irony is a better a project is, the more contributor it attracts.
Meaning it takes a lot of effort by a small group of people, usually 1, to work on a project before the project attracts any contributors, thoughtful bug reporters if ever, and in the end have a good reputation.
And an older a project gets, the more chances the original author is gone, meaning it lost a committed maintainer with deep project knowledge…
And Baloo is a lot older than fsearch…
Was fsearch devs ever sponsored would also play a role. baloo was orginally sponsored to be created as port of nepomuk project, but it faltered 15 years ago or so.
Also this is well-known issue generally
Would you be interested to help?
We still need baloo to be more transparent when it get stuck on a particular file, like hitting a particular pdf file https://bugs.kde.org/show_bug.cgi?id=518476
It should stop indexing a file, if it takes more than a minute.
Lately it got more reliable at deleting corrupted database, and have it less likely.
i see your point…
I would help but unfortunately my skills are not even close to what would be required to contribute… I know only python.
My was more of a user feedback thing… for what it’s worth.
Fsearch is based on a cli app called fzf, i don’t exactly know how that works but it’s blazingly fast and it does not do indexing or stuff… Maybe you want to look into that.
Anyway sorry if my feedback sounded pretentious or wathever… And thanks for your kind feedback
Does fsearch search the contents of pdf, text, and office documents?
This is what the indexing is for, and indexing can be turned off.
Btw Baloo - KDE Community Wiki has some nice context and help how to diagnose issues, the troobleshooting part.
As an avid Fsearch user I can confirm that it doesn’t index contents, just files. However, it does this blazingly fast and you can set it to do a full scan on launch. I have my entire /home and /etc indexed, including hidden files, and I don’t even notice the indexing when launching the app.
I’d say so, I don’t even notice it’s running unless I have my ‘process’ conky running.
It never got in my way in the last 9 years - except when I had fun learning how to clean up the mess I made myself, due to including a Plex cache folder some years ago…
Then it was horrible.
So I usually put Baloo issues down to user error.
Cool!
Kfind has some similar capabilities, and probably is not as fast, but the vast majority of what I search for are file contents. And from Dolphin’s search, I can use that when searching for file names.
searching in linux is a sore point for many… there are no good answers, only some that work better than others with different sets of tradeoffs.
but i would challenge you on all three of your points:
i’ve tasked baloo to index 100GB worth of data, including the contents, and my baloo index is under 500Mb in size ( do not index hidden files tho, and don’t recommend it).
indexing runs constantly and writes to the index every time i save a file change.
the only time i notice baloo using CPU is when i’ve deleted my index file and building a new one… and even then it does a pretty decent job of staying out of the way when higher priority processes are fired up.
so while it may not be perfect, it does have advantages over something like kfind which brute force stakes over your CPU until it’s done searching the context you gave it, assuming you even know what context to search in, and you remembered to search INSIDE the file before you kicked it off.
I think it’s partly to do with the dependency chain. Sticking to core C++/Qt features doesn’t come with excessive performance overhead.
Easiest way to fix it is to not interact with it:
In my opinion, Baloo indexed searching in KDE is considerably better than it was years ago and I’m appreciative of the developers effort to make it so. Because it is so tightly integrated into KDE plasma, I find it convenient for quite a few searches.
However, especially for those people who find Baloo indexing inadequate for their needs, I strongly recommend recoll. For those people unaware of it, it is a very powerful desktop search engine with its own user interface. By default, you run the index periodically, but it can be set up to index when files changed, so you have the choice.
From a wider perspective, the history of Linux desktop search has been somewhat chequered, even if it seems pretty good today. For example, incredibly, some 20 years ago, there was a project called Beagle. The demos looked amazing, but for some reason it was abandoned. I think in reality, it didn’t work that well at the time, but who knows what might have been possible if development had continued.
Finally, I’ve often thought that the indexing mechanism behind desktop search should not be desktop dependent (as opposed to the user interface). If the underlying technology was the same, or perhaps at least had a similar set of Apis, it might make implementing search in applications more consistent, perhaps along the lines of macOS Spotlight. Having said that, I suspect that would be quite a difficult thing to achieve, given the position we are starting from.