Outdated document search results in Application Launcher?

Help
,
1

I have a long-standing issue under Open Suse (already present in 15.2, now still in 15.6), where the Application launcher will show oudated results. This applies especially to files that don’t exist anymore.

For example, I have reorganized my template files months ago. The file

~/Dropbox/lib/templates/template-timetable-wochenliste-workday.ods

has been renamed to

~/Dropbox/lib/templates/Timetable Wochenliste Workday/template_timetable_wochenliste_workday.ods

in April (now it is July), but the old name still shows up as the first result for “wochenliste”, despite not existing anymore. Note also, that I switched from - to _ as separator, so the entries are more easy to distinguish.

Fig.1 Incorrect search result for "wochenliste" in Application launcher (Alt+F1) vs the actual files in Dolphin.
Fig.1 Incorrect search result for "wochenliste" in Application launcher (Alt+F1) vs the actual files in Dolphin.1023×476 86.7 KB

Fig.2 Incorrect search result for "wochenliste" in "KRunner" (Alt+F2)
Fig.2 Incorrect search result for "wochenliste" in "KRunner" (Alt+F2)567×251 27.4 KB

This is especially surprising, because baloosearch shows the correct results and the issue is not solved by sudo balooctl purge.

Fig.3 Correct search results on the shell with baloosearch.
Fig.3 Correct search results on the shell with baloosearch.787×121 9.21 KB

In the opposite direction, new files don’t show up in the search for a while, while baloo detects them essentially instantly.

Fig.4 New file shows up instantly in baloosearch but not in KRunner, Application Launcher.
Fig.4 New file shows up instantly in baloosearch but not in KRunner, Application Launcher.960×194 23.3 KB

This indicates that there seems to be some caching layer in between that doesn’t invalidate old entries, and doesn’t adequately react to new files. When I’ve been trying to read about this issue before, it was usually claimed that the file search is backed by baloo, which doesn’t seem to be the case, or if so, with extra caching.

Is there some way to invalidate the relevant caches / get the search index to add new files more quickly?

After some more trying around the issue became more clear. I usually use only “Application Launcher”, rarely “KRunner” except for testing something. In KRunner it is clear that the incorrect entry comes from “Recent files”, not from “Desktop Search”, and indeed disabling the “Recent files” plugin removes the incorrect entries. So it seems that the “Recent files” plugin simply lacks any handling of files that have been deleted or moved.

However, the “Desktop Search” plugin still retains the problem of not picking up new files.

2

hi, welcome.

have you tried deleting your ~/.cache folder?

often issues like this stem from a stale cache when sweeping changes are made.

there probably should be a built in clean up process but brute force deletion every once in a while works just as well, esp if you have just finished “tiding up” some part of your system.

3

Tried it, didn’t make a difference. Probably a reboot might be needed additionally,

kwin_x11 --replace &
kquitapp5 plasmashell
plasmashell &

didn’t help though, so it shouldn’t be due to in-memory caches.

Instead it helped to clear the “Recent Files” history in the settings. I guess as Linux users we are a bit too stuck with solving things with rm -rf, though sudo rm -rf --no-preserve-root / often is inviting :slight_smile:

After this I reconfirmed by creating

~/Documents/more-specific-name.odt

and then renaming it to

~/Documents/more-specific-name-changed.odt

and opening it again in Writer. Now both the old and the new name show up in “Recent files”, which is definitely a bug. It would ask too much more “Recent files” to detect file renames, but dropping entries that no longer exist would be quite reasonable.

Also, the file does not show up when disabling “recent files”, while baloosearch more-specifc gives

>>> baloosearch more-specific
/home/klaus/Documents/more-specific-name-changed.odt
/home/klaus/tmp/more-specific-name.odt
Elapsed: 0.460609 msecs

The /tmp one I didn’t mention above, but it makes it clear, that the desktop search plugins don’t use Baloo under the hood.

I’d say, I have some bugs to report. Or update, if I already did, it is a long-standing issue after all :cry:

4

This may be related to your issue:

5

Related, but not a solution. Limiting the retention time for recent files would still retain incorrect entries for months.

6

Created a new bug report for this.