Tracker writes back certain metadata to your files. It for example writes back in XMP the title of a JPeg file, among other fields that XMP supports.
We had a service that runs in the background waiting for signals coming from the RDF store that tell it to perform a writeback.
To avoid that our FS miner would pick up the changes that the writeback service made, and that way index the file again, we introduced a D-Bus API for our FS miner called IgnoreNextUpdate. When the API is issued will the FS miner ignore the first next filesystem event that would otherwise be handled on a specific file.
That API is now among our biggest sources of race conditions. Although we wont remove it from 0.10 due to API promises, we don’t like it and want to get rid of it. Or at least we want to replace all its users.
To get rid of it we of course had to change the writeback service in a way that it wouldn’t need the API call on the FS miner any longer.
The solution we came up with was to move the handling of the signal and the queuing to the FS miner‘s process. There we have all the control we need.
The original reason why writing back was done as a service was to be robust against the libraries, used for the actual writeback, crashing or hanging. We wanted to keep this capability, so just like the extractor is a portion of the writeback system going to run out of process of the FS miner.
When a queued writeback task is to be run, an IPC call to a writeback process is made and returns only when it’s finished. Then the next task in the queue, in the FS miner, is selected. A lot like how the extracting of metadata works.
We have and will be working on this in the writeback-refactor branches next few days.
are you sure that _any_ API promise is enough excuse for race conditions being almost embedded by design?
The API will be deprecated and no longer will its use be recommended. But indeed, we can’t break API in 0.10. Flawed design or not.