If you select "From here" while in the user's home directory, search doesn't work: Even files that are obviously there and are visible in the directory before opening the search don't appear. This happens whether you search for filenames or content (I didn't check further options). Some more observations: * After a while, dolphin notifies the user that baloosearch died: "The process for the baloosearch protocol died unexpectedly." * balooctl status reports: "Baloo File Indexer is running.", Index looks healthy as well. * dolphin's terminal output contains: "Empty filename passed to function" on searching. * dolphin's terminal output sometimes contains: "org.kde.dolphin: slotUrlSelectionRequested: QUrl("file:///{{homedir}}/{{selected folder}}")" after selecting different folders (at somerandom point later?)
But searching explicitly in the home directory rather than "from here" does work?
Created attachment 115140 [details] Screenshot of search bar
I thought that selecting "From here (pholthaus)" is actually the explicit variant that searches in the current folder. The only other option is "Everywhere".
My apologies, I confused myself for a moment there! I meant, does it work when you click "Everywhere"?
Sorry, that has gone missing due to editing the original post. Yes, it works perfectly when you select "Everywhere".
Awesome, thanks for the info. BTW, we have a patch that should fix the issue: https://phabricator.kde.org/D15635
I think it isn't a Dolphin bug but a Baloo bug. If you try to force baloo to search an item (/home/user/foo) in a specific folder from terminal (baloosearch -d /home/user foo), it doesn't find anything, but, if you tell it to search that in the parent folder (baloosearch -d /home foo), it will find it. I don't know how to resolve this bug because I never worked on this project, but there's nothing wrong with Dolphin.
You are correct, and the patch is for Baloo. :)
Excuse me, my internet connection is horrible and I saw the comment too late. Anyway, I compiled the patched code, but the error persists.
Yari, it sounds like you have a different problem, then. I can confirm Patrick's issue but not yours. Would you file a new bug for it? Thanks!
Ok, there isn't any bug, my system's baloo simply didn't index my home directory before a certain date. So, I forced it to index again and it works. I don't know if Patrick's issue is the same that I had, but also unpatched dolphin now works well. Excuse me again but theese are my first approaches to KDE bugs community.
Not a problem, we've all been there. :)
Thank you Nate. Great to hear there is a patch already! Just because it may become useful: I tried to reproduce the bug on another system but was not successful. I don't know what could be the reason for that because both systems are more or less up-to-date although their update cycle is vastly different meaning that the other system did not get a lot of updates in between.
Git commit 95af521127c117c1aebf3a3881a86dc7422a2a11 by Jaime Torres Amate. Committed on 25/09/2018 at 17:20. Pushed by jtamate into branch 'master'. Use String to store UDS_USER and UDS_GROUP of String type. Summary: First crash I get after enabling Dr. Konqi for slaves. UDS_USER and UDS_GROUP are strings, not numbers, therefore I've got an assert (simplified): "udsField & KIO::UDSEntry::UDS_NUMBER", "udsentry.cpp", line=line@entry=113) Use the same methods to get those data as in file. Test Plan: Search an obvious file in $HOME, it is shown. Reviewers: dfaure, #baloo, #frameworks, ngraham Reviewed By: dfaure, #baloo, ngraham Subscribers: ngraham, broulik, kde-frameworks-devel Tags: #frameworks, #baloo Differential Revision: https://phabricator.kde.org/D15635 M +41 -2 src/kioslaves/search/kio_search.cpp M +6 -0 src/kioslaves/search/kio_search.h https://commits.kde.org/baloo/95af521127c117c1aebf3a3881a86dc7422a2a11
I'm on lastest update of user neon and find the issue still present. If i perform a dolphin search with the "From Here" selected, it fails to find any file and always shows no results. If I change the search option to "Your files", it finds the file. I find the same problem to be true from within baloosearch. When I use the -d option to baloosearch, it fails to find the same file that it found without the option. kishore@kishore-x403:~$ baloosearch AN4065 /home/kishore/Projects/Reference/Datasheets/ST/STM32F0 Reference Manual.pdf Elapsed: 2.35966 msecs kishore@kishore-x403:~$ baloosearch -d /home/kishore/Projects/Reference/Datasheets/ST AN4065 Elapsed: 0.329187 msecs kishore@kishore-x403:~$ baloosearch --version Baloo 5.86.0 kishore@kishore-x403:~$
(In reply to Kishore from comment #15) > I find the same problem to be true from within baloosearch. When I use the > -d option to baloosearch, it fails to find the same file that it found > without the option. I wonder what we are doing differently, I've found what may be the same PDF: https://www.waveshare.com/w/upload/d/d9/STM32F0-Reference.pdf Downloaded to: /home/test/Projects/Reference/Datasheets/ST/STM32F0 Reference Manual.pdf a straightforward folder tree, no symlinks. Both the tests work: $ baloosearch AN4065 /home/test/Projects/Reference/Datasheets/ST/STM32F0 Reference Manual.pdf Elapsed: 0,229862 msecs $ baloosearch -d /home/test/Projects/Reference/Datasheets/ST/ AN4065 /home/test/Projects/Reference/Datasheets/ST/STM32F0 Reference Manual.pdf Elapsed: 0,24483 msecs System is a Guest VM: KDE neon 5.22 Ext4 filesystem Plasma: 5.22.5 Frameworks: 5.86.0 Qt: 5.15.3 Kernel: 5.11.0-36-generic (64-bit)