Gnome-Files (Nautilus), Tracker3: Search action with the Full-Text option enabled shows results only from pdf files and exclude .odt .py .md files

When perform a search for example of the word landing using Full Text and What:Anything option in Nautilus

The results is only from pdf files

Inside Document directory have html pdf odt py txt js files and one folder, all those files have inside the word landing page

One alternative is use the terminal

[chris@fedora Documents]$ grep -rwl 'landing' ./
[chris@fedora Documents]$ 

But it doesn’t show results from pdf odt files

About Tracker3

[chris@fedora Documents]$ tracker3 status 
Currently indexed: 127 files, 13 folders
Remaining space on database partition: 99.4 GB (94.57%)
All data miners are idle, indexing complete
[chris@fedora Documents]$ 

I forgot to say that the home directory has a partition.

  • /dev/sdb1 / (root)
  • /dev/sdb2 /home
  • /dev/sdb3 swap

How can it be fixed?
Thanks in advance.

I do see results from html, pdf, txt, log, rst, tex files here.

Install dconf-editor perhaps and then see the configuration for the tracker miners. They ignore certain directories and file types and stuff.

Once that is all correct, reindex your directories.


After turn-off and turn-on some option in Settings>Search, Nautilus do show results from .html .txt too but doesn’t show from .py files.

deconf-editor information




In ignored files(dconf-editor) there is no exclusion for .py and files

Note that it is highly encouraged that you copy from your terminal and paste into the post rather than posting multiple screen shots, especially since a lot of screen shots can be of a size that makes them unreadable. Most of the time that is the better choice for readability.

Also, whenever you have text in the search box it will never display anything that does not match that text, as you show above with the first three of your images.

Are these in git repositories? As you see in the settings, tracker ignores folders that have a .git folder in them

No They aren’t.

1 Like

Hrm, no idea then. Try to kill the miners and restart them etc., or to index the files by pointing to them.
tracker3 help index suggests that the command will be:

tracker3 index --add --recursive <dir>

Tracker exclude .odt .py .md files

[chris@f34 ~]$ gsettings list-recursively |grep -i 'org.freedesktop.tracker3.miner.files'
org.freedesktop.Tracker3.Miner.Files index-optical-discs false
org.freedesktop.Tracker3.Miner.Files index-single-directories ['$HOME', '&DOWNLOAD']
org.freedesktop.Tracker3.Miner.Files enable-monitors true
org.freedesktop.Tracker3.Miner.Files index-on-battery-first-time true
org.freedesktop.Tracker3.Miner.Files index-recursive-directories ['&DESKTOP', '&DOCUMENTS', '&MUSIC', '&PICTURES', '&VIDEOS']
org.freedesktop.Tracker3.Miner.Files removable-days-threshold 3
org.freedesktop.Tracker3.Miner.Files ignored-directories ['po', 'CVS', 'core-dumps', 'lost+found']
org.freedesktop.Tracker3.Miner.Files index-on-battery true
org.freedesktop.Tracker3.Miner.Files index-applications true
org.freedesktop.Tracker3.Miner.Files throttle 0
org.freedesktop.Tracker3.Miner.Files ignored-directories-with-content ['.trackerignore', '.git', '.hg', '.nomedia']
org.freedesktop.Tracker3.Miner.Files index-removable-devices false
org.freedesktop.Tracker3.Miner.Files ignored-files ['*~', '*.o', '*.la', '*.lo', '*.loT', '*.in', '*.csproj', '*.m4', '*.rej', '*.gmo', '*.orig', '*.pc', '*.omf', '*.aux', '*.tmp', '*.vmdk', '*.vm*', '*.nvram', '*.part', '*.rcore', '*.lzo', 'autom4te', 'conftest', 'confstat', 'Makefile', 'SCCS', '', 'libtool', 'config.status', 'confdefs.h', 'configure', '#*#', '~$*.doc?', '~$*.dot?', '~$*.xls?', '~$*.xlt?', '~$*.xlam', '~$*.ppt?', '~$*.pot?', '~$*.ppam', '~$*.ppsm', '~$*.ppsx', '~$*.vsd?', '~$*.vss?', '~$*.vst?', 'mimeapps.list', 'mimeinfo.cache', 'gnome-mimeapps.list', 'kde-mimeapps.list', '*.directory']
org.freedesktop.Tracker3.Miner.Files low-disk-space-limit -1
org.freedesktop.Tracker3.Miner.Files crawling-interval -1
org.freedesktop.Tracker3.Miner.Files initial-sleep 15
[chris@f34 ~]$ 
[chris@f34 ~]$ gsettings list-recursively |grep -i 'org.freedesktop.tracker3.extract'
org.freedesktop.Tracker3.Extract text-allowlist ['*.txt', '*.md', '*.mdwn']
org.freedesktop.Tracker3.Extract max-bytes 1048576
org.freedesktop.Tracker3.Extract wait-for-miner-fs false
[chris@f34 ~]$ 
[chris@f34 ~]$ tracker3 search 'landing'

  hello landing page

  Hello my friends landing page…

  hello my friends landing page…

[chris@f34 ~]$ 

[chris@f34 ~]$ tracker3 search

[chris@f34 ~]$ 

[chris@f34 ~]$ tracker3 search





[chris@f34 ~]$ 

[chris@f34 ~]$ ll -a ./Documents/test-search/
total 48
drwxrwxr-x. 2 chris chris 4096 Jul 26 17:03 .
drwxr-xr-x. 9 chris chris 4096 Aug  6 10:26 ..
-rw-rw-r--. 1 chris chris   42 Jul 26 16:04 hello.html
-rw-r--r--. 1 chris chris 8444 Jul 26 16:05 hello.odt
-rw-r--r--. 1 chris chris 9634 Jul 26 16:05 hello.pdf
-rw-rw-r--. 1 chris chris   48 Jul 26 16:02
-rw-r--r--. 1 chris chris   36 Jul 26 16:16 note.txt
-rwxrwxrwx. 1 chris chris  293 Jul 26 16:15
[chris@f34 ~]$

Anybody know why is happen that?

bug reported 1991180

I had to move the .odt .md files to another directory then bring them back, after that tracker3 does show results from .odt .md files, in this example case.
More certainly have to delete/move-to-trash the files to tracker recognize changes in the files.
I realized that .py files are especial becuse in the system could be a lot of .py files, and doesn’t make sense to track those files, but i don’t know if it is right.

[chris@f34 ~]$ tracker3 search 'landing'

  hello landing page

  Hellonew liness landing pageok

  Hello new line ss landing…

  hello my friends landing page…

  …36s  myweb, estudiamosec, landing page 

[chris@f34 ~]$ 

There is a problem when files are updated , in my case the database of tracker3 isn’t realizing about those changes in files, have to delete/move-to-trash and CTRL-Z to undo the action to tracker3 recognize changes in files and show correct results in the command

tracker3 search "landing"

It is important to check disk problems, the problems was the /dev/sdb disk drive, it is a disk that is in bad condition.

How to check ssd health

Install smartmontools in fedora.

#select your disk drive, sdx
[chris@fedora f34cloud]$ sudo smartctl -i /dev/sda |grep "User Capacity"
User Capacity:    480,103,981,056 bytes [480 GB]
[chris@fedora f34cloud]$ 
[chris@fedora f34cloud]$ sudo smartctl -t short -a /dev/sda | grep "SSD_Life_Left"
231 SSD_Life_Left           0x0000   004   004   000    Old_age   Offline      -       96
[chris@fedora f34cloud]$ 

In my case 004 is a bad result, and means problems in that SSD, and that answers some problems of my computers. A good result is maybe 097 .

More info here