GNOME Bugzilla – Bug 751992
gnome-shell search on fresh new tracker db triggers tracker-miner-fs warnings
Last modified: 2015-07-05 20:08:16 UTC
When you search on gnome-shell, it preemptively requests the indexing of the user manual, this triggers the following tracker-miner-fs warnings: (lt-tracker-miner-fs:3744): Tracker-WARNING **: File 'file:///usr' has been reenqueued more than 2 times. It will not be indexed. (lt-tracker-miner-fs:3744): Tracker-WARNING **: File 'file:///usr/share' has been reenqueued more than 2 times. It will not be indexed. (lt-tracker-miner-fs:3744): Tracker-WARNING **: File 'file:///usr/share/gnome-documents' has been reenqueued more than 2 times. It will not be indexed. (lt-tracker-miner-fs:3744): Tracker-WARNING **: File 'file:///usr/share/gnome-documents/getting-started' has been reenqueued more than 2 times. It will not be indexed. (lt-tracker-miner-fs:3744): Tracker-WARNING **: File 'file:///usr/share/gnome-documents/getting-started/C' has been reenqueued more than 2 times. It will not be indexed. (lt-tracker-miner-fs:3744): Tracker-WARNING **: File 'file:///usr/share/gnome-documents/getting-started/C/gnome-documents-getting-started.pdf' has been reenqueued more than 2 times. It will not be indexed. Causing the file not to be indexed. When a file out of tree is requested for indexing, tracker attempts to index all the parent directories until it hits NULL or a known directory, so the process goes: - Attempt to extract deepmost file - see it can't be extracted yet, queue the file back again, and its parent before it - ... (up to the root dir) At this point all files but the root directory will have its retry counter to 2, as each of these has been queued back once. Then directories are processed, from the root down to the requested file. At this point we're forced to process one by one, because each file in the queue depends on the one before it, as processing is async it should go - item_queue_get_next_file() retrieves first item - ::process-file happens (async) - item_queue_get_next_file() looks up the next file, sees it's "blocked", so queues it back again and returns QUEUE_WAIT so we wait until the task finished But at this point we already hit the max nretries limit, this results in all files but / failing. The next run /usr would succeed, the next one /share,... until the file is indexed and this never happens again. I think the first time we increment the counter in this situation is bogus, and we should be resetting it instead.
The following fix has been pushed: 713018b tracker-miner-fs: Reset retry counter when we need to prepend parents
Created attachment 306869 [details] [review] tracker-miner-fs: Reset retry counter when we need to prepend parents The situation where a parent directory has to be prepended in order to process the current file is rare, mainly reserved to IndexFile calls on files out of watched dirs. This is a corner situation, but it is a legit place where we have to put the file back again in the queue, and thus we shouldn't increase the retry counter. This nominally fixes the indexing of gnome-documents-getting-started.pdf on a fresh-out tracker DB, as requested by gnome-shell.