When I am searching inside an indexed location and delete a file in the search results, the file isn't removed from the list. When I run the same query again, the file is still listed but no longer shows a preview. I understand that those results are coming from Nepomuk but it is distracting that I delete a file but have no visual clue that it has succeeded. And Nepomuk should watch file deletion more properly. Reproducible: Always Steps to Reproduce: 1. Go to your "Pictures" folder 2. Hit Ctrl+F 3. Enter search term, eg. "jpg" 4. In the results list delete a file Actual Results: Nothing happens. The file doesn't disappear and I have no idea whether I really deleted it, except that I can no longer open that file. Expected Results: The file gets removed from the list when deleting it was successful. Even if Nepomuk doesn't properly update it, imho it's better to have it erroneously re-apper when querying again than have no feedback at all.
Removing the file from the view without knowing if deleting it really succeeded is IMHO the wrong way to go. It would lead to problems in other situations (like when the file was not actually deleted, and then the user wonders why it has disappeared, much like your very own report bug 319119). Maybe there is a way to fix this inside KIO - note that removing files from remote file systems, where no dir watching is available, does work as expected because KIO notifies us through KDirLister. Anyone who is interested in fixing this might want to investigate how this works inside KIO and how this can be modified such that it works also for searches.
So, you're saying that Dolphin tells KIO to delete the file, this succeeds but the nepomuksearch kio slave doesn't properly update or notify afterwards? So this is more a bug in the KIOslave then?
(In reply to comment #2) > So, you're saying that Dolphin tells KIO to delete the file, this succeeds > but the nepomuksearch kio slave doesn't properly update or notify > afterwards? So this is more a bug in the KIOslave then? Well, if the kioslave notified us through KDirLister, then I think the file would be removed from the view. I'm not really familiar with most of the KIO stuff though, so I'm not entirely sure if it's the kioslave's job to notify us or if the KIO::*Job classes are responsible for that. If you are willing to debug this (which would be much appreciated, of course!), please have a look at the source (comparing with kioslaves where deleting does have the desired effect, like kio_sftp, might help), and/or discuss this with David, who knows a lot more about these things than I do.
I have the same problem for a long time . When I remove or rename a file , the search result is not updated . It shows files which don't exist and the new files (with the new names) aren't found. ' F5 ' does not solve the problem. The only solution is to rename the folder . It's really binding . I often use the filter bar to move, rename or delete my files , and this behavior is very painful. Please correct it, or at least, force the indexation when 'F5' is pressed. Thanks.
To reproduce: 0. A directory with a file named "image_03.jpg" 1. Ctrl-F, enter "03", the above file is found. 2. F2, rename this item "image_04.jpg" 3. Close the filter bar 4. Open the filter bar and enter "04" -> no item is found. 5. Enter "03", "image_03.jpg" is found, but this file doesn't exist!!
*** This bug has been marked as a duplicate of bug 317971 ***