To summarize, Baloo had lots of problems with BTRFS, finally, (above two threads) I made a fresh install with BTRFS.
Just to share my experience hoping it will be of benefit:
After installation (empty /home) I created a text “.txt” file with a few words in it. Edited, rebooted, edited, rebooted,… etc. As expected searching for a specific word I got in Dolphin TWO results of the same file!
So, I assume a snapshot was taken and Baloo reindexed the snapshot. I didn’t install or try anything snapper or any other snapshotting (TimeShift). Are snapshots taken by default through BTRFS itself? Can someone please explain a bit how this happened though I installed nothing or issued any snapshotting commands?
So, I disabled Baloo and purged the index (using sudo to make it permanent). Reboot, edit… move… etc… to test… Everything is working perfect.
I downloaded a PDF book, searching for a word or phrase through Dolphin (content),- though I can select/copy text from the PDF, - not found! This raises a question, content search working fine with .txt file, but not PDF. I read somewhere there is an app/command/service that makes the system treat PDF as a text file! Did I get it right? Couldn’t find this again. Any clue?
I will now install pCloud and Koofr and see how it goes.
I will update you to share experience.
Just thinking, maybe a PDF reader that can “follow” PDFs in /home folder and subfolders can search all file contents?
Thanks for caring to help @smokey
Actually just clicking the file opens it in Okular.
I am trying to find a way to let KDE/Dolphin search PDF content as it does with .txt and .html. I like it is being searched without the need to add an indexing software like Recoll (or Baloo which I disabled because of its problems with BTRFS)
For example, if I want to search for the keyword “poop” in my collection of e-books on politics, I simply run this command:
pdfgrep -r 'poop' ~/Documents/ebooks/Politics/
I have about 1.5 GiB of pdfs in that branch of the filesystem tree, which is on a fairly slow HDD. It takes about a minute to go through them all. On an SSD, it’s a matter of seconds (and it’s a good idea to keep the files you access often on an SSD, of course). No indexing nonsense.
No, no, no… That is 𝖆𝖇𝖘𝖔𝖑𝖚𝖙𝖊𝖑𝖞 𝖕𝖗𝖔𝖕𝖗𝖎𝖊𝖙𝖆𝖗𝖞! I’m afraid that just won’t do.
I believe -at least for me- through a GUI is more convenient. When I search I am most of the time researching, so I need an easy way to find multiple files, open the files I need, open others…
After I downloaded all my files (lots in text .txt) I find searching their content is perfectly fast for me without any indexer installed or running)
I recently replaced my HDD with a SSD!
My understanding that BTRFS makes it even faster (being compressed) (Please correct me if I am wrong)
I just hope to find this service for PDF (again I might be wrong! as usual )
OK. I will try now. Hopefully it works. Maybe I will make a script for convenience (hopefully I will have enough IQ to do a simple script)
Honestly I loved Baloo and had no problem with it (on EXT4). It was one of the main reasons I been on KDE.
But with BTRFS and all the problems of Baloo not playing well with BTRFS, and because I believe BTRFS is the right way to go, it is the future of FS, so I made all this noise about me installing EOS on BTRFS.
Well, the main reason is feeling a bit more secure that I can boot from Grub to a previous working state just in case. Though it can be done through Timeshift under EXT4, but seems to be lot of work to recover if system is unbootable.
And another reason (though might sound stupid) it is my personality! Yes! I tried BTRFS before (maybe September 2021 - you can search my old posts) and it gave me lots of problems. So, for my personality, this is a challenge I will never feel comfortable or settled unless I overcome it!
I assure you if I confronted Godzilla or the Incredible Hulk, I will never give up till I control them or I die! (Sounds stupid I know, especially I know there are bugs in BTRFS and EXT4 is more stable and mature.)
[limo@lenovo ~]$ pdfgrep -r 'economic' /home/limo/Koofr/
terminate called after throwing an instance of 'std::runtime_error'
what(): locale::facet::_S_create_c_locale name not valid
Aborted (core dumped)
Not a good solution (as @petsam correctly pointed out that topic). You’re overriding all your locale settings in your shell, effectively forcing American English for all programs that run in your terminal. It’s much better to set up the locale properly, system-wide. But you do you, this is getting a bit tiresome.