GNOME Bugzilla – Bug 740920
Critical warning when preinserting metadata about a file, in tracker-miner-fs
Last modified: 2014-12-02 22:20:06 UTC
Created attachment 291823 [details] Log file with at the end the critical error Scenario: 1) Mimic what a camera application would do upfront rename() of the temporary file to the destination (after having taken the picture) ie. /home/nemo/Pictures/Camera/20141029_003.jpg : tracker-sparql -qu 'INSERT { _:x a nfo:FileDataObject, nfo:Image, nmm:Photo, nie:DataObject, nie:InformationElement, nfo:Media, nfo:Visual ; nie:url <file:///home/nemo/Pictures/Camera/20141029_003.jpg> ; tracker:available true ; nie:mimeType "image/jpeg" ; nie:title "20141029 003" ; nfo:width 3264 ; nfo:height 1840 ; nfo:orientation "nfo:orientation-top" ; nfo:fileName "20141029_003.jpg" } ' 2) Unexpectedly is tracker-miner-fs picking this up (the file doesn't yet exist, so it shouldn't try to pick this up yet). I conclude this from the log. 3) Create the file. I Mimic what the camera application would do by just using mv, which in the end does rename() too: [nemo@Jolla Jolla]$ mv Jolla_01.jpg ../Camera/20141029_003.jpg
Created attachment 291824 [details] tracker-store's log, who's receiving the write queries
Created attachment 291828 [details] Attempt at fixing this Please review
Comment on attachment 291828 [details] Attempt at fixing this Hi Philip, there is already a function to do what you're doing here called: urn = miner_files_get_file_urn (TRACKER_MINER_FILES (data->miner), file, &is_iri); Which in turn calls tracker_miner_fs_get_urn(). This is important because if we already know the URN from existing caches, it saves the round trip to the DB. As for if the patch is right or not, I am not sure without digging further. Perhaps Carlos can take a look too.
(In reply to comment #3) > (From update of attachment 291828 [details]) > Hi Philip, there is already a function to do what you're doing here called: > > urn = miner_files_get_file_urn (TRACKER_MINER_FILES (data->miner), file, > &is_iri); Aha, and this one will fall back to the SPARQL query in case there's nothing in the caches? > > Which in turn calls tracker_miner_fs_get_urn(). This is important because if we > already know the URN from existing caches, it saves the round trip to the DB. Yep. Reusing caches is better indeed. > As for if the patch is right or not, I am not sure without digging further. > Perhaps Carlos can take a look too. Ok. I'll let Carlos take a look.
I thought there was a patch to fix something similar when I wrote the above coment #3, it seems there is. See bug 678986.
Philip, going to mark this bug as a duplicate, because your suggested patch is something I've reviewed as one of many patches in the other bug mentioned in comment #5. *** This bug has been marked as a duplicate of bug 678986 ***
(In reply to comment #6) > Philip, going to mark this bug as a duplicate, because your suggested patch is > something I've reviewed as one of many patches in the other bug mentioned in > comment #5. > > *** This bug has been marked as a duplicate of bug 678986 *** Argh, customer pressured me to not just report it but to also provide a fix, and now I duplicated the effort :). It indeed looks like this is a duplicate and that the proposed bugfix in that bug is a better approach.