So far, it’s been solid, having just enabled content indexing, I’m sitting at 1.25GB for 10k files. Not bad!
Baloo File Indexer is running
Indexer state: Idle
Total files indexed: 10,621
Files waiting for content indexing: 0
Files failed to index: 0
Current size of index is 1.25 GiB
The real tip in my opinion is to control what is being indexed. A lot of the problems usually come from it trying to index anything and everything and getting stuck on things that it probably shouldn’t be trying to index in the first place. Seems like the KDE devs have been playing wack a mole when it comes to baloo’s defaults for years now, so it is in a much better state these days. However, since the amount, types, and structure of files vary from one system to another it is still common to hit edge cases.
Agreed, limiting it to only local documents in my case, and not allowing it anywhere near folders which are volatile in terms of content (hidden files and folders), seems to work well.
Well, I probably spoke to soon.. after compressing some folders to tar.gz and moving them, my db has ballooned from 1.25GB to 12..
Baloo File Indexer is running
Indexer state: Idle
Total files indexed: 9,735
Files waiting for content indexing: 0
Files failed to index: 0
Current size of index is 12.11 GiB
Setting Baloo to index filenames only (I may end up just disabling it frankly).
Building a little script to put into .bashrc that searches my files and recent content using rg and fzf, which are blazing fast and don’t rely on anything to do with Baloo or semantic search, pentagrams, or small sacrifices to the netherworld.
As below if you find it helpful (just tweak your folders according to your needs in Recent);
search() {
local dir="$HOME/"
local mode file result query line
mode=$(printf "Files\nContent\nRecent\n" |
fzf --prompt="Search > ") || return
case "$mode" in
Files)
file=$(rg --files "$dir" |
fzf --prompt="File > ") || return
xdg-open "$file" >/dev/null 2>&1 &
;;
Content)
read -r -p "Search files for: " query
[ -z "$query" ] && return
result=$(rg \
--line-number \
--no-heading \
--color=always \
"$query" "$dir" |
fzf --ansi --prompt="Match > ") || return
file=${result%%:*}
line=${result#*:}
line=${line%%:*}
vim +"$line" "$file"
;;
Recent)
local recent_dirs=(
"$HOME/Documents"
"$HOME/Downloads"
"$HOME/Desktop"
"$HOME/Pictures"
"$HOME/Music"
"$HOME/Videos"
)
local existing_dirs=()
local d
for d in "${recent_dirs[@]}"; do
[ -d "$d" ] && existing_dirs+=("$d")
done
result=$(
{
# Files directly in $HOME, but no hidden files/directories
find "$HOME" \
-maxdepth 1 \
-type f \
! -name '.*' \
-printf '%T@\t%TY-%Tm-%Td %TH:%TM\t%p\n' \
2>/dev/null
# Recursively search normal user-facing directories
if [ ${#existing_dirs[@]} -gt 0 ]; then
find "${existing_dirs[@]}" \
-type f \
-printf '%T@\t%TY-%Tm-%Td %TH:%TM\t%p\n' \
2>/dev/null
fi
} |
sort -nr -k1,1 |
head -n 500 |
cut -f2- |
fzf --prompt="Recent > "
) || return
file=${result#*$'\t'}
xdg-open "$file" >/dev/null 2>&1 &
;;
esac
}
This why I use FSEARCH. Yes, it can’t read file content, but it won’t slow down my system, nor create a massive index file, AND I can have it index everything and anything on internal and external devices.
If I need to search for content within a file, I open a folder inside Kate or Obsidian.
PS: Just checked the size of the database file for FSEARCH.
It’s only 191.7 MB for over 3.5 million files!!!
No wonder the app opens so quickly when launched.
Some additional information in case anyone is interested:
I build it from source - not the AUR - since it’s easy to do. I use an alias.
Building it takes seconds.
Files are found instantly so long as they’ve been indexed.
You can set FSearch to re-index for new files every few hours.
It has RegEx and blob search patterns.
It uses 600 MB - 1 GB of memory when open, whether while indexing or idle.
