baloosearch6 <string> returns a list of files withing the home directory (BTW, incomplete). baloosearch6 -d <home_directory> <same_string> returns nothing. STEPS TO REPRODUCE 1. baloosearch6 -d $HOME <whatever> SOFTWARE/OS VERSIONS Operating System: Gentoo Linux 2.15 KDE Plasma Version: 6.1.3 KDE Frameworks Version: 6.4.0 Qt Version: 6.7.2 Kernel Version: 6.10.1-gentoo (64-bit)
Cannot reproduce; works for me exactly as described with current git master.
Likely https://bugs.kde.org/show_bug.cgi?id=474973#c27 That used to happen when you had system running BTRFS (such as OpenSUSE and latterly Fedora), the system gave no guarantee that the BTRFS partition was mounted with the same device number as it had on the previous boot... Files were then indexed multiple times and filtering for files under a given folder quite often failed.... The solution is to summon up patience and purge and reindex clean. That was my mistake not noticing the effect of the patch on non-BTRFS systems, see Bug 477068
Although I use BTRFS, this behaviour can be observed without remounting the partition between indexing and queering.
(In reply to Eugene Shalygin from comment #3) > Although I use BTRFS, this behaviour can be observed without remounting the > partition between indexing and queering. If you want to step through the tests... Maybe there's an effect we've not identified.... For one-of-your-files.txt, try: $ baloosearch -i one-of-your-files.txt You might get more then one "hit". The "-i" asks baloosearch to show the internal DocID that Baloo uses, if you get more than one result with different DocIDs and the same directory/filename then you'd had (now or sometime in the past) the BTRFS device number problem. You can check the details for the file on your filesystem with "stat": $ stat one-of-your-files.txt and make a note of the "Device" line. It will have the Device Number and iNode. If you reboot the device number may change. Previously Baloo was confused by this change, now it digs deeper and reads the FSID of the filesystem (which does not change) and bases the DocId on that. If you reboot and see the stat details change and baloosearch give the same results as before, then you are on safe ground. You will however need to reindex: $ systemctl --user stop kde-baloo $ baloctl purge $ systemctl --user start kde-baloo and you can watch the reindexing progress with "balooctl monitor". It might take a while. If your balooserch results continue to change, we'll have to dig down and see what filesystem is (anything layered on top of BTRFS?)
(In reply to tagwerk19 from comment #4) > If you want to step through the tests... Maybe there's an effect we've not identified.... Did you find anything?
baloosearch6 - d $HOME seems to be working, but content search does not return matches I'd expect it to include. For example, it finds a certain string inside a PDF file, but does not find it in .c source files...
(In reply to Eugene Shalygin from comment #6) > ... but does not find it in .c source files ... There's a set of exclusions for code, they are defined as mime-type exclusions which means that Baloo indexes the filenames and metadata but not the content. You can see what's excluded with: $ balooctl6 config list excludeMimetypes | sort and remove the exclusion for C with $ balooctl6 config rm excludeMimetypes text/x-csrc and C headerfiles with $ balooctl6 config rm excludeMimetypes text/x-chdr You can do similar for C++ if you wish. ... You may find you need "balooctl" rather than "balooctl6"
Thank you! This is really unexpected that baloo does exclude something by default, and there is no hint to that in the KCM page. May I ask why does it exclude basically all the file types I would like it to index?
(In reply to Eugene Shalygin from comment #8) > ... This is really unexpected that baloo does exclude something by > default, and there is no hint to that in the KCM page. May I ask why does it > exclude basically all the file types I would like it to index? ... I agree it's pretty well concealed, it was a surprise to me. My guess of "why" is that it is easy to download (and delete) large code repositories and this could really slug Baloo, although deleting repositories is still more work than it should be... Two things have changed, you download to SSD's now rather than HDD's and there's been a strict cap introduced to the memory use of Baloo. It can now index without affecting the rest of the system.
🐛🧹 ⚠️ This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information, then set the bug status to REPORTED. If there is no change for at least 30 days, it will be automatically closed as RESOLVED WORKSFORME. For more information about our bug triaging procedures, please read https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging. Thank you for helping us make KDE software even better for everyone!
🐛🧹 This bug has been in NEEDSINFO status with no change for at least 30 days. Closing as RESOLVED WORKSFORME.