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 715204 - editable_id field is deleted when photos are lost, and not restored when they are found
editable_id field is deleted when photos are lost, and not restored when they...
Status: RESOLVED OBSOLETE
Product: shotwell
Classification: Other
Component: ux
unspecified
Other All
: High normal
: ---
Assigned To: Shotwell Maintainers
Shotwell Maintainers
Depends on:
Blocks:
 
 
Reported: 2013-11-25 12:56 UTC by Shotwell Maintainers
Modified: 2021-05-19 11:08 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Data from photos.db from before, during, and after the file loss (16.52 KB, application/vnd.oasis.opendocument.spreadsheet)
2013-11-25 12:56 UTC, Shotwell Maintainers
Details

Description Charles Lindsay 2013-11-25 21:36:06 UTC


---- Reported by shotwell-maint@gnome.bugs 2013-11-25 04:56:00 -0800 ----

Original Redmine bug id: 7717
Original URL: http://redmine.yorba.org/issues/7717
Searchable id: yorba-bug-7717
Original author: Sean Lanigan
Original description:

I initially noticed this when I took away the hard drive holding my photos and
then opened Shotwell. Naturally, all the photos were moved to "Missing Files".
After this though, I continued to import and edit new photos, for several
months. When I restored the hard drive and re-opened Shotwell, although the
photos were now moved out of Missing Files, the edits I had made to them using
Photivo (i.e. using an external editor) were lost. The photo file itself was
still present, but Shotwell had lost the link between the original and the
edit. Luckily, I have backups of the photo.db database from both before I
removed the drive, and before I reintroduced the missing files. With a little
experimentation, I am able to get either all of the "old" photos and their
edits back perfectly (but obviously missing my new imports), or all of my
"new" imports and those edits but with the "old" edits missing.

I decided to further investigate. I first backed-up everything, and then
renamed the Shotwell database directory so Shotwell would run as though it was
just installed. I set the photos folder to a new, temporary one.

  * I imported about 20 photos I have, including some which were RAW+JPEG pairs. This all went fine. 
  * I opened some of the photos using an external editor, made some obvious changes, and saved the file to the <image>_modified.jpg that Shotwell created.
  * I used sqliteman to take a look at the photo.db file, and documented the fields I thought were important from the "phototable" and "backingphototable" into a spreadsheet. Of note was how the "editable_id" field in "phototable" pointed to the corresponding id in "backingphototable" for the edits that I had made. 
  * I closed Shotwell, then renamed the temporary folder which held the photos. 
  * I opened Shotwell. The photos were correctly marked as missing. I then closed Shotwell.
  * I examined photo.db again. I noticed that compared to before the files went "missing", the "develop_shotwell_id", "develop_camera_id", and "develop_embedded_id" fields were not changed in "phototable". However, the "editable_id" fields were all set to -1. I imagine that "flags" and "backlinks" also changed, but I did not look at these as they did not seem relevant. Furthermore, I noticed that in "backingphototable", the last five rows (which is how many photos I edited) disappeared, presumably because their id was no longer linked in "phototable".
  * I now changed the filename of the temporary photos folder back to its original name, and re-opened Shotwell. It found the files, and moved them out from "Missing Files" 
  * I examined again photo.db. Apart from the changes I presume take place to "flags" and "backlinks" in "phototable", no changes to the id fields happened. The links between the edited photos and their id in backingphototable were not restored, and as a result the edited photos were lost to Shotwell - despite still existing in exactly the same place in the filesystem. However, the RAW+JPEG pairs still have the JPEG correctly assigned to the RAW.

I have attached the spreadsheet I made during my investigation, in case it is
of assistance. You can see for yourself how the backingphototable is
truncated.

I have not looked at any of the code for Shotwell, yet. But I imagine it would
be simple enough to change Shotwell such that when a photo goes missing, the
"editable_id" is kept intact, in the same manner that "develop_shotwell_id",
"develop_camera_id", and "develop_embedded_id" is. It seems inconsistent that
the RAW+JPEG pairs are kept intact, but not edits to the images.
backingphototable should be kept intact, and be able to be restored when the
files re-appear. Could such a fix be implemented to prevent future users from
losing their photo edits from being lost to Shotwell?

It is unfortunate that this means my personal Shotwell database has been
somewhat damaged, and there is not a simple fix to get Shotwell to recognise
my edited photos. However, I should think that with some manipulation I can
hopefully restore the necessary ids and fields in the database to get all of
my edits back. Perhaps a deeper fix would be to have Shotwell recognise any
suffix of "_modified" as a version of the photo that has the same name, then
the database would not be necessary to identify versions of the same photo.



--- Bug imported by chaz@yorba.org 2013-11-25 21:36 UTC  ---

This bug was previously known as _bug_ 7717 at http://redmine.yorba.org/show_bug.cgi?id=7717
Imported an attachment (id=261491)

Unknown version " in product shotwell. 
   Setting version to "!unspecified".
Unknown milestone "unknown in product shotwell. 
   Setting to default milestone for this product, "---".
Setting qa contact to the default for this product.
   This bug either had no qa contact or an invalid one.
Resolution set on an open status.
   Dropping resolution 

Comment 1 GNOME Infrastructure Team 2021-05-19 11:08:11 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to GNOME's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/shotwell/-/issues/348.