Summary: | SCAN : upgrade to 3.5.0 caused loss of collection, re-adding caused loss of tags | ||
---|---|---|---|
Product: | [Applications] digikam | Reporter: | Rainer Dorsch <ml> |
Component: | Database-Scan | Assignee: | Digikam Developers <digikam-bugs-null> |
Status: | RESOLVED INTENTIONAL | ||
Severity: | normal | CC: | caulier.gilles, freisim93, gazhay, swatilodha27 |
Priority: | NOR | ||
Version: | 3.5.0 | ||
Target Milestone: | --- | ||
Platform: | Debian unstable | ||
OS: | Linux | ||
Latest Commit: | Version Fixed In: | 5.7.0 | |
Sentry Crash Report: |
Description
Rainer Dorsch
2013-11-09 18:34:23 UTC
I could narrow down the problem, which may allow to find the root cause: I restored the old db file: From the restored file I get sqlite> select * from AlbumRoots; 2|family|0|1|volumeid:?uuid=3bfc8f7b-628c-425d- af32-269e98a8f36e|/home/rd/Rohdaten/digiKam sqlite> There is no reference on /scratchbox/... whatsover. But on stderr I see then, when starting digikam: digikam(16814)/digikam (core) Digikam::AlbumRootLocation::AlbumRootLocation: Creating new Location "/home/rd/Rohdaten/digiKam" uuid "volumeid:?uuid=3bfc8f7b-628c-425d-af32-269e98a8f36e" digikam(16814)/digikam (core) Digikam::CollectionManager::updateLocations: location for "/scratchbox/users/rd/scratchbox/home/rd/Rohdaten/digiKam" is available true /scratchbox/users/rd/scratchbox/home/rd/Rohdaten/digiKam is wrong and this triggers all the problems. To validate: if I add a symlink which creates /scratchbox/users/rd/scratchbox/home/rd/Rohdaten/digiKam everything is fine. Let me try to illustate (unfortunately I cannot fully explain), why digikam runs into trouble without that artificial symlink: digikam finds /scratchbox/users/rd/scratchbox/home/rd/Rohdaten/digiKam does not exist and now digikam identifies a lot of removed stuff: digikam(16814)/digikam (core) Digikam::KMemoryInfo::update: Platform identified : "LINUX" digikam(16814)/digikam (core) Digikam::KMemoryInfo::bytes: TotalRam: 4239216640 digikam(16814)/digikam (core) Digikam::LoadingCache::setCacheSize: Allowing a cache size of 200 MB digikam(16814)/digikam (core) Digikam::ThumbnailSchemaUpdater::startUpdates: Have a thumbnail database structure version "2" digikam(16814)/digikam (core) Digikam::ThumbnailLoadThread::initializeThumbnailDatabase: Thumbnail db ready for use digikam(16814)/digikam (core) Digikam::CollectionScanner::itemsWereRemoved: Removed items: () related items: () digikam(16814)/digikam (core) Digikam::CollectionScanner::itemsWereRemoved: Removed items: () related items: () digikam(16814)/digikam (core) Digikam::CollectionScanner::itemsWereRemoved: Removed items: (36481, 36482, 36483, 36484, 36485, 36486, 36487, 36488, 36489, 36490, 36491, 36492, 36493, 36494, 36495, 36496, 36497, 36498, 36499, 36500, 36501, 36502, 36503, 36504, 36505, 36506, 36507, 36508, 36509, 36510, 36511, 36512, 36513, 36514, 36515, 36516, 36517, 36518, 36519, 36520, 36521, 36522, 36523, 36524, 36525, 36526, 36527, 36528, 36529, 36530, 36531, 36532, 36533, 36534, 36535, 36536, 36537, 36538, 36539, 36540, 36541, 36542, 36543, 36544, 36545, 36546, 36547, 36548, 36549, 36550, 36551, 36552, 36553, 36554, 36555, 36556, 36557, 36558, 36559, 36560, 36561, 36562, 36563, 36564, 36565, 36566, 36567, 36568, 36569, 36570, 36571, 36572, 36573, 36574, 36575, 36576, 36577, 36578, 36579, 36580, 36581, 36582, 36583, 36584, 36585, 36586, 36587, 36588, 36589, 36590, 36591, 36592, 36593, 36594, 36595, 36596, 36597, 36598, 36599, 36600, 36601, 36602, 36603, 36604, 36605, 36606, 36607, 36608, 36609, 36610, 36611, 36612, 36613, 36614, 36615, 36616, 36617, 36618, 36619, 36620, 36621, 36622, 36623, 36624, 36625, 36626, 36627, 36628, 36629, 36630, 36631, 36632, 36633, 36634, 36635, 36636, 36637, 36638, 36639) related items: () For a full stderr see http://bokomoko.de/~rd/kde-327377-stderr.log I cannot tell for sure, why digikam gets the wrong directory, but let me check for the uuid from AlbumRoots: sqlite> select * from AlbumRoots; 2|family|0|1|volumeid:?uuid=3bfc8f7b-628c-425d- af32-269e98a8f36e|/home/rd/Rohdaten/digiKam sqlite> check for the uuid: rd@blackbox:~/tmp.nobackup$ mount|grep 3bfc /dev/disk/by-uuid/3bfc8f7b-628c-425d-af32-269e98a8f36e on / type ext4 (rw,noatime,discard,errors=remount-ro,data=ordered) /dev/disk/by-uuid/3bfc8f7b-628c-425d-af32-269e98a8f36e on /scratchbox/users/rd/scratchbox type ext4 (rw,noatime,discard,errors=remount- ro,data=ordered) /dev/disk/by-uuid/3bfc8f7b-628c-425d-af32-269e98a8f36e on /scratchbox/users/rd/dev type ext4 (rw,noatime,discard,errors=remount- ro,data=ordered) rd@blackbox:~/tmp.nobackup$ It seems that digikam gets confused by several mounts with the same device uuid.... Since I do not know what algorithm digikam implements here to derive the uuid, it is hard for me to provide further data. Let me know if you can identify which additional data would be helpful to find the root cause of the problem. Unmounting the /scratchbox/... dirs is a workaround for the problem. I think the problem was not introduced by the upgrade from digikam 3.4 to 3.5, I consider it more likely that it is related to the upgrade of my Debian distribution to jessie (but still it is likely a bug in digikam). Thanks, Rainer We use the UUID to identify the partition. We do not store the mount path, only the path on the partition and the UUID. I assume the converter tried to map the path from the old id to the path, which failed as it is certainly not prepared to have the root partition remounted several times. What is the use case for this? I got it through the scratchbox SDK for the Nokia N900 phone. Note, they are not just mounting the same partition at two different mount points: blackbox:~# ls -l /scratchbox/users/rd/scratchbox insgesamt 56 drwxrwsr-x 18 root sbox 4096 Okt 31 23:17 ccache drwxr-xr-x 6 root sbox 4096 Jun 2 2011 compilers drwxr-xr-x 16 root sbox 4096 Jun 2 2011 dev drwxr-xr-x 6 root sbox 4096 Jun 2 2011 device_tools drwxr-xr-x 11 root sbox 4096 Jun 2 2011 devkits drwxr-xr-x 2 root sbox 4096 Jun 2 2011 doc drwxr-xr-x 6 root sbox 4096 Jun 2 2011 etc drwxr-xr-x 4 root sbox 4096 Jun 2 2011 host_shared -rwxr-xr-- 1 root sbox 7165 Aug 27 2009 login drwxr-xr-x 3 root sbox 4096 Jun 2 2011 packages drwxr-xr-x 2 root sbox 4096 Jun 2 2011 sbin drwxr-xr-x 12 root sbox 4096 Jun 2 2011 tools drwxr-xr-x 3 rd users 4096 Dez 12 2009 users blackbox:~# ls -l / insgesamt 112 drwxr-xr-x 2 root root 4096 Dez 30 2007 backup drwxr-xr-x 2 root root 4096 Nov 3 19:21 bin drwxr-xr-x 5 root root 4096 Nov 10 14:35 boot lrwxrwxrwx 1 root root 11 Dez 28 2007 cdrom -> media/cdrom lrwxrwxrwx 1 root root 9 Jul 25 2008 data -> /opt/data drwxr-xr-x 15 root root 3680 Nov 10 17:05 dev drwxr-xr-x 224 root root 20480 Nov 10 14:37 etc drwxr-xr-x 10 root root 4096 Apr 20 2013 home drwxr-xr-x 2 root root 4096 Dez 28 2007 initrd lrwxrwxrwx 1 root root 31 Nov 3 19:32 initrd.img -> /boot/initrd.img-3.10-3-686-pae lrwxrwxrwx 1 root root 32 Nov 4 2012 initrd.img.old -> /boot/initrd.img-3.2.0-4-686-pae drwxr-xr-x 22 root root 12288 Nov 6 00:41 lib drwx------ 2 root root 16384 Dez 28 2007 lost+found drwxr-xr-x 4 root root 4096 Sep 20 08:43 media drwxr-xr-x 22 root root 4096 Nov 10 12:09 mnt drwxr-xr-x 12 root root 4096 Nov 9 21:50 opt dr-xr-xr-x 264 root root 0 Nov 9 18:51 proc drwxr-xr-x 47 root root 4096 Nov 10 13:02 root drwxr-xr-x 35 root root 1240 Nov 10 10:41 run drwxr-xr-x 2 root root 12288 Nov 3 19:22 sbin drwxr-xr-x 14 rd users 4096 Nov 10 10:04 scratchbox drwxr-xr-x 2 root root 4096 Dez 28 2007 srv dr-xr-xr-x 13 root root 0 Nov 9 18:51 sys drwxrwxrwt 20 root root 600 Nov 10 18:43 tmp drwxr-xr-x 10 root root 4096 Dez 29 2011 usr drwxr-xr-x 12 root root 4096 Nov 3 19:15 var lrwxrwxrwx 1 root root 27 Nov 3 19:32 vmlinuz -> boot/vmlinuz-3.10-3-686-pae lrwxrwxrwx 1 root root 28 Nov 4 2012 vmlinuz.old -> boot/vmlinuz-3.2.0-4-686-pae blackbox:~# If you want to understand in more detail what happens, see the mount scripts they use http://bokomoko.de/~rd/sbox_mount_all and http://bokomoko.de/~rd/sbox_mount I did not try to understand how their setup works, I just used their scratchbox SDK so far. Details how to use and get it are provided here https://developer.nokia.com/Community/Wiki/Maemo_5_SDK_installation_for_beginners Thanks, Rainer To make the entire process more robust, would it make sense to store the mount path and the uuid? If both are consistent, then there is no need to guess a new mount path. If they are not consistent, do whatever you do now. Rainer I can confirm this bug. Just launched digikam, it moved my entire collection of photos to the trash and created an sqlite file in the location where my photos used to be. (Ubuntu 13.10) Luckily I caught the problem, as digikam asked me for a new library location on launch and checking in nemo I could see the folder had gone. I managed to restore before someone emptied my trash, but this is an unforgivable error. This file still valid using last digiKam 4.2.0 ? Gilles Caulier Do you still face the issue using digiKam 5.0.0 version ? Please provide necessary updates, if any. Any feedback with current AppImage bundle for Linux ? https://drive.google.com/drive/folders/0BzeiVr-byqt5Y0tIRWVWelRJenM Gilles Caulier This crash is relevant of KHTML. Since digiKam 5.x we use Qt5::WebView instead. Gilles Caulier This is about migration to digiKam version 3, not KHTML. Keeping it closed as wontfix as the affected versions (2->3) are ancient. |