GNOME Bugzilla – Bug 771042
Would be nice to keep the URN stable across atomic file updates
Last modified: 2021-05-26 22:24:25 UTC
We can now share images (to email, online accounts) from gnome-photos. If the image was sent to a location that we otherwise index (like an online account), we set up some properties in Tracker to link the original with the shared copy. We also embed some XMP metadata in the original file to identify the shared copy, in case we lose the DB and have to restore the properties. The problem is that embedding XMP metadata via gexiv2/exiv2 causes an atomic update of the file - a temporary copy of the file is created, then the metadata is added to it and the file is renamed to replace the original. This causes the URN to change. I am wondering if we can avoid that. In the short term, I am planning to detect the URN change myself. I know the URN of the file that is about to be updated, and since it is a local file I can compare the nie:url to check if it is the same file or not. With that I can wait for /org/freedesktop/Tracker1/Resources::graph-update to tell me what the new URN is. It would be nice, however, if Tracker somehow dealt with it on its own. (This makes me wonder about writeback. When Tracker writes metadata back to the file, it doesn't affect the URN. How does that work? Or am I mistaken about the whole thing? I am not intimately familiar with exiv2's I/O classes, so maybe it is doing something funky which I missed?)
(In reply to Debarshi Ray from comment #0) > The problem is that embedding XMP metadata via gexiv2/exiv2 causes an atomic > update of the file - a temporary copy of the file is created, then the > metadata is added to it and the file is renamed to replace the original. > This causes the URN to change. I am wondering if we can avoid that. That was with F24 and an SDD. While testing things on my other laptop (F23 with rotating HDD), I observed that Tracker interpreted the rename as a 'change' instead of a 'delete + create'. Hence the URN didn't change. I guess the underlying storage technology messes with the various timeouts in Tracker and GIO.
(In reply to Debarshi Ray from comment #0) > In the short term, I am planning to detect the URN change myself. I know the > URN of the file that is about to be updated, and since it is a local file I > can compare the nie:url to check if it is the same file or not. With that I > can wait for /org/freedesktop/Tracker1/Resources::graph-update to tell me > what the new URN is. FYI, I have now committed this workaround to gnome-photos (see bug 770267).
GNOME is going to shut down bugzilla.gnome.org in favor of gitlab.gnome.org. As part of that, we are mass-closing older open tickets in bugzilla.gnome.org which have not seen updates for a longer time (resources are unfortunately quite limited so not every ticket can get handled). If you can still reproduce the situation described in this ticket in a recent and supported software version, then please follow https://wiki.gnome.org/GettingInTouch/BugReportingGuidelines and create a new enhancement request ticket at https://gitlab.gnome.org/GNOME/tracker/-/issues/ Thank you for your understanding and your help.