Version: 0.10.0-rc1 (rev.: 923581) (using KDE 4.1.4) Compiler: gcc (GCC) 4.3.0 20080428 (Red Hat 4.3.0-8) x86_64 platform OS: Linux Installed from: Fedora RPMs I started with three collections on the local disk: $ ls /home/plouj/dkPictures/ /home/plouj/Photos/ /home/plouj/Pictures/ /home/plouj/dkPictures/: g2data g2data-from-plouj.com-again digikam4.db-journal /home/plouj/Photos/: 2007 2008 Aleks /home/plouj/Pictures/: 2008-02-07--15.45.26 2008-05-20--14.08.47 2008-06-20--18.52.36 2008-08-23--14.29.31 2008-11-05--18.51.13 gt-shots digikam4.db 2008-02-09--11.27.47 2008-06-03--18.54.13 2008-06-24--18.39.53 2008-09-15--17.37.22 2008-12-06 kleinburg roy-thompson-hall.jpg 2008-03-09--13.01.49 2008-06-07--21.03.12 2008-07-19--12.54.45 2008-09-17--09.34.21 2008-12-17 new-york-for-big-prints roy-thompson-hall.xcf 2008-03-09--18.54.05 2008-06-12--19.24.00 2008-07-21--21.59.31 2008-10-09--19.45.29 2008-12-31 recepie 2008-04-12--13.51.12 2008-06-15--17.38.25 2008-07-23--19.20.31 2008-10-12--16.05.41 2009-01-01 test 2008-04-12--14.22.30 2008-06-18--22.06.04 2008-07-24--17.40.13 2008-11-01--12.16.18 2009-02-01 wallpapers Then I moved all of the albums/files to the ~/Pictures/ collection: $ mv dkPictures/* Pictures/ $ mv Photos/* Pictures/ Then I started digikam with gdb, it crashed at the splash screen. All attach the full backtrace separately.
Created attachment 31238 [details] full console output with a gdb backtrace I'm actually attaching the full console output including the gdb backtrace in case that information is useful.
Look at this in your console output: Failure executing query: database disk image is malformed There is something wrong with your database file. The crash comes from deep within sqlite3, digikam code cannot influence this as far as I see. Additionally you have the file "digikam4.db-journal" in your file listing up there, that should be a temporary file, I have never seen it live. The database file is digikam4.db.
I restored all of my collection directories to the state in a recent backup and deleted the digikam4.db-journal file. As a result, digikam doesn't crash anymore. I still wonder why the .db-journal file was created and if a similar situation could totally confuse a user who doesn't know about that file's existence and purpose.
(In reply to comment #3) > I still wonder why the .db-journal file was created and if a similar situation > could totally confuse a user who doesn't know about that file's existence and > purpose. > These files are always created when a database transaction is done. This is why sqlite3 is slower than for example MySQL, because of the disk access. I guess digiKam crashed while doing some db stuff so the journal file was not cleaned up.