Created attachment 1811931 [details] from virtual machine Created attachment 1811931 [details] from virtual machine Description of problem: After run tracker3 search 'landing' There is no result from .js .py .odt .dm files But in a virtual machine there does result from odt and .dm files but no from .py files Attached will be 2 videos - from host - from guest virtual machine Version-Release number of selected component (if applicable): tracker 3.1.2-1.fc34 How reproducible: create some files .odt .pdf .js .html .txt README.md ,py and writes inside those the word 'landing' and any others words Attached will be a tar.gz folder with my testing files Steps to Reproduce: 1. Create a directory inside Document cd Document mkdir tst-search && cd test-search 2. create some files: .py .odt .pdf .html .js .README.md .txt 3. write inside those files the word 'landing' and some other words and save them. 4. open the terminal, from home directory run the command tracker3 search 'landing' Actual results: There is no result from .py .odt .md .js but in a virtual machine does it show result from .odt .md Expected results: Results from .py .md .odt .js files too. Additional info: [chris@f34 test-search]$ 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', 'ltmain.sh', '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 test-search]$ [chris@f34 test-search]$ 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 test-search]$
Created attachment 1811932 [details] from host , there is no result from .py .odt .md .js files from host , there is no result from .py .odt .md .js files
Created attachment 1811933 [details] the directory of my test files the directory of my test files
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. 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' Results: file:///home/chris/Downloads/student-girl-studying-laptop-landing-page-template student-girl-studying-laptop-landing… file:///home/chris/Documents/test-search/hello.html hello landing page file:///home/chris/Documents/test-search/hello.odt Hellonew liness landing pageok file:///home/chris/Documents/test-search/hello.pdf Hello new line ss landing… file:///home/chris/Documents/test-search/note.txt hello my friends landing page… file:///home/chris/Documents/test-search/README.md …36s myweb, estudiamosec, landing page [chris@f34 ~]$
Created attachment 1812131 [details] results from nautilus, after remove and bring them back it works well
In my case is there a problem after update files. Tracker3 doesn't realized about updates in files. For example after remove the word 'landing' in the .odt file tracker3 persist showing results from that file, despite the word was removed.
my partitions: home is in a volume grou LVM ask-fedora: https://ask.fedoraproject.org/t/gnome-files-nautilus-tracker3-search-action-with-the-full-text-option-enabled-shows-results-only-from-pdf-files-and-exclude-odt-py-md-files/15748 ```bash [chris@f34 ~]$ lsblk -f NAME FSTYPE FSVER LABEL UUID FSAVAIL FSUSE% MOUNTPOINT sda ├─sda1 ntfs New Volume A254DEF854DECDE3 └─sda2 crypto_LUKS 1 d687b472-083a-401b-9405-fa4e336440ca sdb ├─sdb1 btrfs volbtr 498318bf-439f-461d-9218-853d0f91928f 80.7G 19% / ├─sdb2 LVM2_member LVM2 001 kFAIla-HKFN-TKfb-2dTR-9Y3u-4kCR-ZxiJeD │ └─vg1-home ext4 1.0 4b1b7e82-a603-4817-88ae-3aa3770e96ba 57.8G 36% /home └─sdb3 swap 1 a191a4aa-78bc-464d-ae44-41ee9bb21a36 [SWAP] sdc ├─sdc1 vfat FAT32 5670-9433 54.6M 43% /boot/efi ├─sdc2 ├─sdc3 ntfs 00EE92CBEE92B87C └─sdc4 ntfs 68E2BA7EE2BA4FD4 sr0 zram0 [SWAP] [chris@f34 ~]$ ```
More certainly have to delete/move-to-trash the files in question, then CTRL-Z to undo that action, then tracker3 does recognizes changes and show correct results in the commands tracker3 search ''landing'
This message is a reminder that Fedora Linux 34 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora Linux 34 on 2022-06-07. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a 'version' of '34'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, change the 'version' to a later Fedora Linux version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora Linux 34 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora Linux, you are encouraged to change the 'version' to a later version prior to this bug being closed.
Fedora Linux 34 entered end-of-life (EOL) status on 2022-06-07. Fedora Linux 34 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. Thank you for reporting this bug and we are sorry it could not be fixed.