Version: (using KDE KDE 3.5.1) Installed from: Compiled From Sources OS: Linux 3 bugs / unexpected behaviors of kfind search result using "file index" (locate). 1) Results are not always in the folder that is searched: Steps to reproduce: - Two directories "/dir" and "/dir2", have them and their content in your locate db (updatedb). - run kfind, searching for e.g "*" in directory "/dir" or "file:///dir" using file index. - search results include content of "/dir2", too. - if you search for "*" in dir "file:///dir/", the problem doesn't exist any more. Solution: in kquery.cpp, there's a line "*processLocate << m_url.path().latin1();". write "*processLocate << m_url.path( 1 ).latin1();" instead, this will append a trailing "/", if there is none. 2) Unclean path, e.g. "/home/user/../user" confuses locate. Steps to reproduce: - run kfind using file index / locate on the above url; kfind / locate doesn't give any search results, but without using file index, kfind works as expected. Solution: run "m_url.cleanPath();" in kquery.cpp before the actual search starts. (for example, just above the line "*processLocate << m_url.path( 1 ).latin1();"). 3) Sub path, that's the same as the absolute path of the directory to be searched confuses kfind using file index. Steps to reproduce: - have directories "/home/user/dir" and "/home/user/someotherdir/home/user/dir" in your locate db. - search "/home/user/dir". this will give results in "/home/user/someotherdir/home/user/dir" which is unexpected. Solution: For every result reported by slocate, check, whether it's inside the directory we wanted to search. This can be done by using "if ( m_url.isParentOf(file->url()) ) processQuery(file);" instead of simply "processQuery(file);" in function "void KQuery::slotListEntries( QStringList list )". Continue with your great work, KDE team!
I think 3) is behaviour of the locate command, thus expected.
The first two bugs were fixed (with your suggestions). Thanks a lot.
In my opinion, using the option "Use file index" should not show different results than the usual search. I think, the usual user doesn't know (and doesn't care) what locate / updatedb ... is. He only sees the result, and the name "Use file index" doesn't really show, what's going on (although the What's this help does indeed say "slocate..."). Therefore I wrote, that this behavior is "unexpected", not unexpected in a sense of programming, but of usability.
Dear Bug Submitter, This bug has been stagnant for a long time. Could you help us out and re-test if the bug is valid in the latest version? I am setting the status to NEEDSINFO pending your response, please change the Status back to REPORTED when you respond. Thank you for helping us make KDE software even better for everyone!
Dear Bug Submitter, This is a reminder that this bug has been stagnant for a long time. Could you help us out and re-test if the bug is valid in the latest version? This bug will be moved back to REPORTED Status for manual review later, which may take a while. If you are able to, please lend us a hand. Thank you for helping us make KDE software even better for everyone!
I checked all three issues (using the numbering of my comment #1 of 2006, kde 3.5.1): 1) same issue as before: create /home/user/test and /home/user/test2, put a file into /home/user/test2, run updatedb. Run kfind (search for "*" within folder /home/user/test). Without "use file index" will correctly display empty search result (because the folder /home/user/test is empty), while with "use file index" enabled, this will incorrectly display the file within /home/user/test2 as search result, which is a bug. Likely, a possible solution is stated in my comment 12 years ago (append trailing slash / to the path for the locate search). 2) bug seems to be fixed, I cannot reproduce it. 3) I cannot reproduce it, likely fixed or not an issue any more. My system today is: KFind Version 18.04.3 KDE Frameworks 5.46.0 Qt 5.9.6 (compiled against 5.9.4) xcb windows manager
Thank you for reporting this issue in KDE software. As it has been a while since this issue was reported, can we please ask you to see if you can reproduce the issue with a recent software version? If you can reproduce the issue, please change the status to "REPORTED" when replying. Thank you!
Dear Bug Submitter, This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information as soon as possible and set the bug status as REPORTED. Due to regular bug tracker maintenance, if the bug is still in NEEDSINFO status with no change in 30 days the bug will be closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging If you have already provided the requested information, please mark the bug as REPORTED so that the KDE team knows that the bug is ready to be confirmed. 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. The bug is now closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging Thank you for helping us make KDE software even better for everyone!