Re: [Tracker] Review request, bug fixed by a downstream integrator (Jolla)

[Martyn Russell <martyn lanedo com>]

On 10/07/14 12:10, Philip Van Hoof wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>
> Hi Martyn,
>
> This is a comment by developer a from the bug:
>
> "
>
> tracker-control -s starts tracker (which fails because it is already
> re/started by systemd).
>
> I was able to reproduce this with some minimal steps :
>
> [nemo Jolla Camera]$ cp ../x_files_12.jpg .
> [nemo Jolla Camera]$ tracker-search -i 2>/dev/null | wc -l
> 479
> [nemo Jolla Camera]$ tracker-search -i 2>/dev/null | wc -l
> 480
> [nemo Jolla Camera]$ systemctl --user restart tracker-miner-fs.service
> [nemo Jolla Camera]$ tracker-control -F

OK, so you have ca. 480 files *indexed*, then you restart.

> Store:
> 27 Jun 2014, 13:21:25: ? Store - Idle
>
> Miners:
> 27 Jun 2014, 13:21:25: 68% File System - Processing? unknown time left
> 27 Jun 2014, 13:21:25: ? Extractor - Idle
> 27 Jun 2014, 13:21:25: ? Applications - Not running or is a disabled
> plugin
> Press Ctrl+C to end follow of Tracker state
> 27 Jun 2014, 13:21:29: 72% File System - Processing? unknown time left
> 27 Jun 2014, 13:21:30: 83% File System - Processing? unknown time left
> 27 Jun 2014, 13:21:35: 87% File System - Processing? unknown time left
> 27 Jun 2014, 13:21:36: 98% File System - Processing? unknown time left
> 27 Jun 2014, 13:21:40: ? File System - Idle
> 27 Jun 2014, 13:21:42: ? File System - Processing?
> 27 Jun 2014, 13:21:42: ? File System - Idle
> ^C
> Received signal:2->'Interrupt'
> [nemo Jolla Camera]$ tracker-search -i 2>/dev/null | wc -l
> 60

So where did they go?
I don't see a delete command anywhere?

Also, what surprises me about this is that I would expect 
tracker-miner-fs to find the files on second start.

However, this is likely related to the configuration used. We don't 
force an mtime check in all cases.

My first question would be: what setting is the 'crawling-interval' set 
to AND, did the SIGTERM (presumably) given by systemctl to Tracker 
create a "clean" shutdown, because if it did, Tracker won't force a 
check on all directories on restart. But all of this is academic if the 
content is not there any more?

> This is still reproducible on latest upstream release 1.0.1 and master
> ( but fixes a lot of other potential crashes ).
>
> Reverting [1] fixes this scenario. That commit was implemented for us
> in bug 16427

OK, but I don't actually understand the reason why this is happening 
just yet or really what is going on. Restarting Tracker mid-index should 
only delay indexing further, it shouldn't just skip ca. 420 files that 
actually exist.

Thanks,

--
Regards,
Martyn

Founder & Director @ Lanedo GmbH.
http://www.linkedin.com/in/martynrussell