https://bugs.kde.org/show_bug.cgi?id=353874
--- Comment #21 from tagwer...@innerjoin.org --- (In reply to Bug Janitor Service from comment #20) > A possibly relevant merge request was started @ > https://invent.kde.org/frameworks/baloo/-/merge_requests/113 >From the MR: > ... After I applied this patch, killed baloo_file, deleted an indexed file, > and started baloo_file again, > the deleted file didn't appear anymore in the balooseach results. That didn't > happen with the > unpatched baloo, the deleted file was still there and trying to open it with > KRunner did nothing ... So the test sequence is: Create a test file Check that it is indexed (including file content) Kill baloo Delete the file Restart baloo and check whether the file is still in the index. Yes, the file is still in the index, as per baloosearch. This is slightly more specific than comment 0 but consistent with what I've seen when having deleted a large folder and not waiting until baloo has cleared all its entries or if there are too many deletes and notifications "overflow", as mentioned in https://bugs.kde.org/show_bug.cgi?id=437754#c1 It might be worth mentioning a couple of the wraiths in the mist... Where the device number has changed and baloo reindexed the files, deleting the test file even when baloo_file is running will not result in the earlier entry being removed. This is in the cases with BTRFS and multiple subvols, such as with openSUSE, where "baloosearch -i searchstring" shows several hits with different DocIDs, see https://bugs.kde.org/show_bug.cgi?id=402154#c12 There's also the possibility that krunner caches the data from baloo and presents remembered results... Revisited with Neon Unstable: Plasma: 5.27.80 Frameworks: 5.104.0 Qt: 5.15.8 Kernel: 5.19.0-35-generic (64-bit) -- You are receiving this mail because: You are watching all bug changes.
