After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 741583 - tracker-miner-fs fails when a file is renamed
tracker-miner-fs fails when a file is renamed
Status: RESOLVED DUPLICATE of bug 678986
Product: tracker
Classification: Core
Component: Miners
1.2.x
Other Linux
: Normal critical
: ---
Assigned To: tracker-general
Depends on:
Blocks:
 
 
Reported: 2014-12-16 07:55 UTC by Cosimo Cecchi
Modified: 2014-12-16 16:23 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
patch (1.39 KB, patch)
2014-12-16 11:39 UTC, Cosimo Cecchi
none Details | Review

Description Cosimo Cecchi 2014-12-16 07:55:40 UTC
Using tracker 1.2.4, when a file is renamed, the file system miner will print out a critical warning, and fail to update the index for that file.

This is the warning:
(tracker-miner-fs:2392): Tracker-CRITICAL **:   (Sparql buffer) Error in task 0 of the array-update: Subject `(null)' is not in domain `nfo:FileDataObject' of property `nfo:fileName'
(tracker-miner-fs:2392): Tracker-CRITICAL **: Could not execute sparql: Subject `(null)' is not in domain `nfo:FileDataObject' of property `nfo:fileName'

I found a reference of this very same error message in this commit by Sam: https://mail.gnome.org/archives/commits-list/2014-August/msg06580.html
Comment 1 Cosimo Cecchi 2014-12-16 09:10:09 UTC
This seems to only happen for regular files, and not for directories.
Comment 2 Cosimo Cecchi 2014-12-16 11:39:58 UTC
Created attachment 292800 [details] [review]
patch

This patch seems to fix it for me, but I am not 100% sure of the approach.
Rationale in the commit message - comments welcome!
Comment 3 Sam Thursfield 2014-12-16 12:41:23 UTC
Thanks for the patch! As you noted, I also spotted, but failed to fix (or report) this issue .. 

Looks like https://git.gnome.org/browse/tracker/commit?h=68559df979fe70c4d473026354fe963407fa5db7 introduced this bug, and I guess that setting 'force = TRUE'  is effectively just reverting the behaviour back to how it was before, so shouldn't have any serious performance implications.
Comment 4 Martyn Russell 2014-12-16 14:44:52 UTC
I have a strong suspicion this bug 678986 is related and the patch(es) there are a more comprehensive solution.

I believe Philip and I are waiting on Carlos for input before committing.

Thanks Cosimo.
Comment 5 Cosimo Cecchi 2014-12-16 16:23:15 UTC
Oh indeed - my patch is actually exactly the same of https://bugzilla.gnome.org/attachment.cgi?id=289394 which is marked as accepted-commit_now :-)

Closing as a duplicate.

*** This bug has been marked as a duplicate of bug 678986 ***