File system miner doesn't enforce ignored-directories-with-content for newly created files
When a recursively-indexed directory contains any of the files specified by /org/freedesktop/tracker/miner/files/ignored-directories-with-content
(such as .trackerignore
or .git
), any files & directories created in that directory will still get recursively indexed. However, when hard-resetting Tracker and restarting it, those files do not get indexed, as expected.
In other words, the issue is that when files/folders are created in a location below a recursively-indexed directory, those items will be indexed even if that location had been marked as one to not index via the presence of a ignored-directories-with-content
file.
I encountered this bug earlier today when my computer spent 100% CPU on Tracker after compiling a project that I cloned from Github. By default, .git
is one of the files that should stop Tracker from indexing a directory, so the project folder should not have been indexed, but it was anyways. This means that the common scenario of cloning a large git repo may make Tracker work very hard (if the project is large enough, or if compiled files are placed in the project directory), even though Tracker shouldn't do anything at all.
Steps to reproduce:
- Make sure that
~/Documents
is a recursively-indexed folder (it is by default). - Create a folder
~/Documents/extra
. - In that folder, create a file named
.trackerignore
. - In that same folder, create a text file named
cant_find_me.txt
. - After a few seconds, run
tracker info cant_find_me.txt
.
Actual results: tracker info
will return information for that file, indicating that it was indexed.
Expected results: tracker info
should return no information, indicating that the file was not indexed.