https://bugs.kde.org/show_bug.cgi?id=267131
[email protected] changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|FIXED |--- Status|RESOLVED |REOPENED CC| |[email protected] --- Comment #29 from [email protected] --- Apologies if I shouldn't have reopened this (or reported it as a feature requested), however it seems that this still is a major usability issue. Use case: - Someone (like me) creates a Digikam database, spends lots of time editing it with careful backups. - Migrates it to another disk (either because moving disks, or moving computers, or a failed disk, or views it on another computer). The expected behavior is that everything still works. Actual behavior is that database becomes corrupted, and I had to use a backup because I did not know how to tell digikam to "match up" files (comment #23). The instructions (comment #27) to hit the refresh-icon button next to the database to change its type were "mostly correct" but did not work, since it lost all my tags and seemingly corrupted the database. However I eventually got it to work (see far below). People coming to this bug probably need a way to 'uncorrupt' the database and recover their tags, because they've likely run digikam thinking that nothing should go wrong, but it has. See comment #14 "Copying a collection to a new disk is a standard user operation for moving, upgrading, restoring from backups. These operations should not break digiKam to the point where it cannot be fixed from within the application." I believe some similar data loss caused me to give up on digikam a very very long time ago, without writing a bug for it. People were seemingly confused http://digikam.185.s1.nabble.com/use-of-uuid-in-database-td3492022.html and it still seems to be causing problems for people today (because they eventually migrate their collection to new computers, because they don't keep their old computer forever). Maybe someone could chime in how to recover from losing all tags by having digikam rescan the DB. However this is how I "recovered" the database from a backup once I realized something was going wrong: # I had previously backed up the database cp -r collection/digikam ~/temp/digikam-dir-backups/backup-17 # realize something going wrong exit digikam mv collection/digikam ~/temp/digikam-dir-backups/digikam-post-new-disk-corrupted cp -r ~/temp/digikam-dir-backups/backup-17 collection/digikam # THIS IS IMPORTANT: DO NOT mv YOUR BACKUP INTO PLACE THEN TRY TO EDIT IT; when recovering from a backup, copy FROM your backup (obviously) # (then I changed the database type in Settings > Collections > "refresh" icon [should be changed to a text button with better symbology], but when this failed I noted the change in the db tables with sqlitebrowser, destroyed the db again, and recovered again from (e.g. backup-17), all for the express purpose to see what was going on; you don't have to do this as I noted the changes for you below...) # edit the recovered-from-backup SQL database with your favorite tool sqlitebrowser collection/digikam/digikam4.db previous AlbumRoots table entries (before migration) INSERT INTO "main"."AlbumRoots" ("id", "label", "status", "type", "identifier", "specificPath", "caseSensitivity") VALUES ('1', 'library', '0', '1', 'volumeid:?uuid=aeb623be-3509-47a4-b93f-2a4fcb5acad5&fileuuid=ab6XXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX', '/home/yourusername/path/to/collection', '2'); ...should become (changing mountpath and fileuuid as appropriate)...: INSERT INTO "main"."AlbumRoots" ("id", "label", "status", "type", "identifier", "specificPath", "caseSensitivity") VALUES ('1', 'library', '0', '3', 'networkshareid:?mountpath=/home/yourusername/path/to/collection&fileuuid=ab6XXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX', '/', '2'); In e.g. sqlitebrowser, you can edit the table cells individually. In summary, find the relevant row of the collection in the AlbumRoots table, then: - change its .type from 1 to 3, and - change its .identifier from 'volumeid:?uuid=...&fileuuid=...' to 'networkshareid:?mountpath=/home/yourusername/path/to/collection&fileuuid=INSERT OLD FILEUUID' (not sure what file uuid is or is for) - change its .specificPath to '/' See if this works, let digikam load up and 'refresh' everything (not sure what steps should be taken to rescan database in e.g. maintenance), let it run overnight doing any upkeep until the CPU usage is low, then look if things seem to be working. Make a new backup snapshot. To summarize, I think comment #6 said: "What is essential is that when digikam feels lost it should ask for a corrected root - not automatically remove all tags. [Can it be "Scan for new items at startup (makes startup slower)" that causes this automatic tag deletion?] Digikam should work on album restored from a backup to a different disk, currently it does not." The problem is that people expect the databases of type Local (is this the default? 'local' 100% seems like what you want to use, but is deceptive because it is 99% not what anyone wants to use and is a misnomer), and 99% of users have a ticking issue that will only bite them a few years down the road. The solution is to: 1) Not 'lose' or corrupt the entire collection (without any way to prompt the user to recover it) if the collection AlbumRoot merely seems moved (instead prompt the user about the problem with a description of the problem); 2) Create a third type of database, the default, called 'Default' or 'Local (v2)' or 'Default Local Path', which is just an alias to a network share with a local path, and prompt all users to migrate to it 3) Rename 'Local' to 'ByDiskUUID (obsolete)' and obsolesce it, unless there is a specific use case for disk UUID. 4) Force-migrate eveyone very carefully to the new Default (non-UUID) setup. 5) (Perhaps rename the Database Migration dialog to "Database sqlite<->MySQL Migration", or update the Database Migration dialog to handle the use case of "the AlbumRoot is not found; where is it?" and/or to recover the database (it's unclear if it's possible to migrate a database from /some/path to the same /some/path and if that would be a useful thing to do given the use of UUIDs). Currently it is unclear if that tool (which I had no idea exists) is for use before or after moving the database or what its purpose is, so maybe it should automatically show up when needed and tell the use what to do and how to use it. However upon closer inspection, it currently seems to only be for changing between sqlite and MySQL.) -- You are receiving this mail because: You are watching all bug changes.
