Is tracker scanning Downloads again (despite the folder being ignored)?

I’ve been downloading some lecture videos from my university from youtube, and noticed unusually high CPU usage during that process. Turns out, tracker-miner-fs-3 and tracker-extract-3 together were keeping 1-2 CPU cores busy … I am using youtube-dl which crates intermediary files for each fragment of the download, so I assume that’s what’s keeping tracker busy.

However, due to security and privacy concerns, I have turned off Search / indexing of $HOME/Downloads in GNOME Settings, which should prevent tracker from looking for files in the Downloads folder at all. Does tracker 3 no longer respect those settings? I can think of no other reason for its high CPU usage, since my PC was idle other than those video downloads …

Additionally, this activity seems to crash tracker-extract-3 regularly, since ABRT is accumulating crash reports for it (24 crashes and counting).


Can you see what it’s doing with strace?

1 Like

Check this:

gsettings list-recursively \
| grep -i -e "tracker.*ignored-dir" -e "tracker.*index-.*dir"

This is the output of the gsettings query:

$ gsettings list-recursively | grep -i -e "tracker.*ignored-dir" -e "tracker.*index-.*dir"
org.freedesktop.Tracker3.Miner.Files index-single-directories ['$HOME', '&DOWNLOAD']
org.freedesktop.Tracker3.Miner.Files index-recursive-directories ['&DOCUMENTS', '&MUSIC', '&PICTURES', '&VIDEOS', '/home/deca/University']
org.freedesktop.Tracker3.Miner.Files ignored-directories ['po', 'CVS', 'core-dumps', 'lost+found']
org.freedesktop.Tracker3.Miner.Files ignored-directories-with-content ['.trackerignore', '.git', '.hg', '.nomedia']
org.freedesktop.Tracker.Miner.Files index-single-directories ['$HOME', '&DOWNLOAD']
org.freedesktop.Tracker.Miner.Files ignored-directories ['po', 'CVS', 'core-dumps', 'lost+found']
org.freedesktop.Tracker.Miner.Files index-recursive-directories ['&DOCUMENTS', '&MUSIC', '&PICTURES', '&VIDEOS', '/home/deca/University']
org.freedesktop.Tracker.Miner.Files ignored-directories-with-content ['.trackerignore', '.git', '.hg', '.nomedia']

This is what strace shows for tracker-miner-fs-3 (many of those in a short time, file name “redacted” by me):

statx(AT_FDCWD, "$FILENAME", AT_STATX_SYNC_AS_STAT|AT_SYMLINK_NOFOLLOW|AT_NO_AUTOMOUNT, STATX_ALL, {stx_mask=STATX_ALL|STATX_MNT_ID, stx_attributes=0, stx_mode=S_IFREG|0664, stx_size=40629933, ...}) = 0

This does indeed look like tracker is indexing the Downloads folder, despite the GNOME Settings GUI showing that this is turned off:

Turning this setting for Downloads folder on and off again has no effect on the gsettings values. Looks like the tracker / tracker 3 / gnome-settings-center don’t talk to each other anymore :slight_smile:

1 Like

Can you file a bug and propose it as prioritized, please?

1 Like


1 Like

It looks like you have installed both old and new tracker packages.
I guess you should remove the old one:

sudo dnf remove tracker

And exclude downloads from indexing:

gsettings set org.freedesktop.Tracker3.Miner.Files \
    index-single-directories "['\$HOME']"

I’ve been able to remove the “old” tracker packages without issues, looks like the default package now set no longer requires them. They were installed because I upgraded from fedora 32.

However, now GNOME Settings doesn’t let me change Search locations at all. Looks like it expects the old tracker 2 GSettings keys to be present, which explains why it doesn’t affect tracker 3.

Huh. Why are they packaged to coexist?

@decathorpe, you can edit index locations with gsettings or dconf-editor as noted above to exclude the download directory from indexing.

@mattdm, it seems that some packages still depend on it:

> sudo dnf -q repoquery --whatrequires tracker-miners

IIRC, they were packaged separately because not all GNOME components finished the transition to tracker 3 in time for GNOME 3.38, so both versions needed to be shipped with fedora 34.

you can edit index locations with gsettings or dconf-editor as noted above to exclude the download directory from indexing.

Yeah, sure, I’ve done that now. Still the default UI for this is broken …

Also, indexing Downloads by default sounds like a bad idea. I definitely remember discussion about turning this off by default for security reasons, but maybe that was never actually implemented :confused: