Database corruption of TagTable when manipulating hierarchical tags
Submitted by an unknown user
Link to original bug (#718118)
Description
---- Reported by shotwell-maint@gnome.bugs 2011-12-22 03:16:00 -0800 ----
Original Redmine bug id: 4525
Original URL: http://redmine.yorba.org/issues/4525
Searchable id: yorba-bug-4525
Original author: Bruce Smith
Original description:
Ubuntu 11.10, 64-bit. Shotwell 0.11.6 from the Ubuntu release distribution.
There is bug, or maybe two bugs if one is pedantic, with manipulation of hierarchical tags. These bugs lead to corruption of TagTable. These were the reason that led me to the failed database editing that I reported under http://redmine.yorba.org/show_bug.cgi?id=4511.
Suppose I have the following hierarchy of tags (two levels deep) - these values are in the Name field in TagTable
- /Orchids/Microtis
- /Orchids/Microtis parviflora
- /Orchids/Microtis unifolia (Onion Orchid)
I wish to re-arrange these tags so that I have the following hierarchy (three levels deep) - this is how it should finally be represented in TagTable
- /Orchids/Microtis/Microtis sp
- /Orchids/Microtis/Microtis parviflora
- /Orchids/Microtis/Microtis unifolia (Onion Orchid)
In this hierarchy, I want the photos with the tag "/Orchids/Microtis" (#1 (moved) in the topmost list) to eventually have this tag instead "/Orchids/Microtis/Microtis sp"
To achieve this, my planned procedure is
- Rename "Orchids/Microtis" to be "Orchids/Microtis sp" - at this point I have "Orchids/Microtis parviflora", "Orchids/Microtis unifolia (Onion Orchid)" and "Orchids / Microtis sp" --- the tag called plain "Orchids / Microtis" has now disappeared
- Create a new (empty) tag "/Orchids/Microtis"
- Drag & drop "/Orchids/Microtis parviflora", "/Orchids/Microtis unifolia (Onion Orchid)", "/Orchids/Microtis sp" to this new tag "/Orchids/Microtis", thereby creating the desired hierarchy
The first bug occurs at the Rename step 1 above. What happens is that in TagTable I now have these modified rows
- /Orchids/Microtis sp
- /Orchids/Microtis sp parviflora
- /Orchids/Microtis sp unifolia (Onion Orchid)
To accompany this database corruption, there are visual clues too. The sidebar has changed from
- Microtis
- Microtis parviflora
- Microtis unifolia (Onion Orchid)
to
- Microtis sp
- Microtis sp parviflora
- Microtis sp unifolia (Onion Orchid)
So the original bug is that during the rename, if there are other tags starting with the same string, then their Name fields are also (wrongly) changed.
That brings me to the second bug.
If I do not notice the visual clues in the Shotwell UI after the rename, but instead continue with my process at step 2, where I add the new (empty) tag "/Orchids/Microtis", that creates (as expected) a new row in TagTable with Name "/Orchids/Microtis" - all is well so far.
But when I drag-and-drop "Microtis sp" to "Microtis" to create the first of the 3-deep hierarchy, I get a visual clue that all is not well, and I also get further database corruption.
The visual clue is that "Microtis parviflora" and "Microtis unifolia (Onion Orchid)" have disappeared from under the top-level tag "Orchids" in the side bar; "Microtis" and its child "Microtis sp" are all that is left of this part of the tree under "Orchids" (no other child tags or trees under "Orchids" are affected, only the Microtis section)
In the database, the 3 Microtis-related rows that existed after the Rename operation have been replaced by 4 new rows with these values in the Name field
- /Orchids/Microtis
- /Orchids/Microtis/Microtis sp
- /Orchids/Microtis/Microtis sp//Orchids/Microtis sp parviflora
- /Orchids/Microtis/Microtis sp//Orchids/Microtis sp unifolia (Onion Orchid)
In the first 2 of these rows, the photo_id_list field is identical.
I apologise that my description of this bug is so long-winded --- it has taken me quite a while to figure out a reproducible sequence of events.
I'm quite happy to ZIP up my photo.db (the one I saved before all this experimentation started) if you need it to help reproduce.
Related issues: duplicates shotwell - 4190: If one sibling tag's name begins with a substring that ma... (Fixed)
---- Additional Comments From shotwell-maint@gnome.bugs 2013-05-01 11:46:00 -0700 ----
History
Comment 1
Updated by Adam Dingle almost 2 years ago
- Priority changed from Normal to High
- Target version set to 0.12
Bruce,
Thanks a lot for the detailed bug report. Superficially this looks like 4190, which we've fixed in the development trunk for the upcoming 0.12 release. Could you possibly build Shotwell from git master and see if the problem still occurs there? If it does, then we should certainly investigate more.
Comment 2
Updated by Bruce Smith almost 2 years ago
Thanks Adam. Sure, am trying to build the latest source (obtained by "git clone git://yorba.org/shotwell"). A few notes so far.
In addition to the dependencies listed at http://yorba.org/shotwell/install/, I find that I need libgtk-3-dev, libwebkitgtk-3.0-dev, libunique-3.0-dev
I set my Vala compiler to be 0.12 as per the build instructions, but "make" complained as follows:
bruce@calochilus:/tmp/shotwell$ make
Shotwell requires Vala compiler 0.15.0 or greater. You are running 0.12.1.
make: *** [plugins/shotwell-plugin-dev-1.0.vapi] Error 1
bruce@calochilus:/tmp/shotwell$
It seems that the Vala compiler installed with Ubuntu 11.10 is 0.12
bruce@calochilus:/tmp/shotwell$ valac --version
Vala 0.12.1
bruce@calochilus:/tmp/shotwell$
Would you please advise? Is the advice on the build instructions page inaccurate, or have I omitted some important step?
Comment 3
Updated by Eric Gregory almost 2 years ago
Bruce, the build instructions are for the release tarball.
To build the latest and greatest from Git, you'll have to download Vala 0.15 and build it yourself (thankfully this isn't that difficult to do!)
Vala source can be downloaded from here:
Comment 4
Updated by Bruce Smith almost 2 years ago
Thanks Eric. I downloaded and built and installed the 0.15 source version of Vala. Then I was able to build Shotwell from Git (it says it is 0.11.90+trunk).
I confirm that this version has fixed the bug(s) that led to corruption of the TagTable in the database. Thank you !!!
I also confirm that this release has fixed an annoyance of all previous releases that provide hierarchical tags with drag-and-drop ---- in 0.11.90+trunk, when a drag-and-drop is initiated, after the mouse button is released and the operation completes, the sidebar is now positioned at the point of the drag-and-drop target --- previously it had gone right back to the top (over Library). This is goodness !!!!
I have found a problem with 0.11.90+trunk though --- when in "normal display mode", the thumbnails of all my pictures are blank. If I double-click on a photo, then in the "full view" it is displayed properly. If you aren't aware of this behaviour already, then I have a log file that I just captured & will supply if required.
Comment 5
Updated by Adam Dingle almost 2 years ago
- Status changed from Open to 5
- Resolution set to duplicate
OK - great to hear that you're not seeing the tag corruption in the trunk build. So I think this bug is indeed a duplicate of #4190 (closed), and I'm marking it as such.
It's surprising to hear that your thumbnails are blank - I don't think we've seen this before. If you start with a fresh database directory (e.g. 'shotwell -d foo') and then reimport photos, do you still see blank thunbnails?
Comment 6
Updated by Charles Lindsay 7 months ago
- Status changed from 5 to Duplicate
--- Bug imported by chaz@yorba.org 2013-11-25 21:55 UTC ---
This bug was previously known as bug 4525 at http://redmine.yorba.org/show_bug.cgi?id=4525
Unknown Component Using default product and component set in Parameters 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.
Version: 0.12
Resolution: RESOLVED DUPLICATE