GNOME Bugzilla – Bug 771630
Nautilus not show files Indexed by tracker
Last modified: 2021-06-18 15:50:01 UTC
Description: Yesterday, I changed tracker preference to not index file contents ( to speed up indexing process and decrease size ) and suddenly after re-indexing, nautilus gnome-shell search-provider stop working. After looking in the source code I found that the culprit is following line g_string_append_printf (sparql, " fts:match '\"%s*\"'", search_text); in https://git.gnome.org/browse/nautilus/tree/src/nautilus-search-engine-tracker.c which will eventually filter files indexed with no contents. though commenting that line solve the problem for me, it seems like it probably need a better fix. Steps to reporoduce: 1. open tracker-preferences - go to controll tab - untick "Index content of files found" and "Index numbers" 2. run "tracker reset --hard;tracker daemon -f" Tested on Nautilus 3.20.3 Arch Linux x86_64 Linux 4.4.15-1-lts
*** This bug has been marked as a duplicate of bug 764587 ***
Hi, After I upgraded to 3.22 (Arch Linux). The problem still exist. Although bug 764587 is targeting the same line in the source code, it's not a duplicate of this bug. The patch provided inside Bug 764587, still need the files to have contents. So if "Index content of files" is disabled in tracker preferences, nautilus won't find any file no matter what you type(prefix or fullname). The only solution as I mentioned above is to remvove content matching filter or g_string_append_printf (sparql, " fts:match '\"%s*\"'", search_text); in https://git.gnome.org/browse/nautilus/tree/src/nautilus-search-engine-tracker.c in the case that file have no content
We cannot do that in practice, as it would require reading the content. Not sure what a good fix would be for this...
A better solution probably is check whether file have any content avalible or not If there isn't any, then the filter should not be based on the file content, else check the content, I have some free time this weekend so If you don't mind I could create a patch around this
(In reply to Bijan Binaee from comment #4) > A better solution probably is check whether file have any content avalible > or not > If there isn't any, then the filter should not be based on the file content, > else check the content, > I have some free time this weekend so If you don't mind I could create a > patch around this I my previous comment I said this is not doable in practice, since it requires to read the content. We cannot do that for performance.
Aha.... Still other alternative solutions may put into action. Solution 1: 1. Query for the suggestion using content based filter 2. If nothing shows up query again without content filter. * This probably not affect performance at all (it is O(1) solution). Solution 2: 1. Check tracker preferences in GSetting for "Index content of files found" 2. If it's enabled then skip content filtering * Altough this may create confustion not affect performance at all
GNOME is going to shut down bugzilla.gnome.org in favor of gitlab.gnome.org. As part of that, we are mass-closing older open tickets in bugzilla.gnome.org which have not seen updates for a longer time (resources are unfortunately quite limited so not every ticket can get handled). If you can still reproduce the situation described in this ticket in a recent and supported software version of Files (nautilus), then please follow https://wiki.gnome.org/GettingInTouch/BugReportingGuidelines and create a new ticket at https://gitlab.gnome.org/GNOME/nautilus/-/issues/ Thank you for your understanding and your help.