digikam will not start with pictures stored on either an NFS or a CIFS disk

[Havard Bjastad]

I have just installed Ubuntu 6.06 on 2 machines, both of which access an NFS server (where pictures are stored). When I try to start digikam, I get the following error:

"Failed to update old Database to new Database format"

After searching the web, this seems to be caused by missing NFS file locking.

Digikam used to work fine on both machines, one running Ubuntu 5.10 and the other Fedora Core 4. Now, with both running Ubuntu 6.06 with the latest upgrades, neither work.

I have installed portmap (which seems to be required) and nfs-common, but still get the error message.

[senfkruste (klstocki)]

Version: 0.8.0 (using KDE 3.5.0, Arch Linux)
Compiler: Target: i686-pc-linux-gnu
OS: Linux (i686) release 2.6.15-archck

i have a nfs-server, where the home-dirs are stored. All my pictures although stored on an nfs-export. Now, when i tell digikam, that the album-path should be on the nfs-export digikam won´t start. It occures an error "The database could not be actualiced from old to new format" and digikam crashes. When i set the album-path to an non nfs-export (=local) digikam starts fine.

[Toma-u (toma-u)]

This is a sqlite problem. Nothing we can do.

[Pierre Habouzit (madcoder)]

you can still make the error message states that it's an NFS locking problem, do you ?

I can understand that you don't want to fix sqlite, but having the user aware that's it's due to an NFS problem would be nice

[Tom Albers (tomalbers-deactivatedaccount)]

digiKam uses sqlite. Sqlite has problems with NFS. Hence digiKam does not support image libraries stored on NFS.

[Havard Bjastad (havard-bjastad)]

Hmmm, strange then that it worked so well when I was running Fedora Core 4 and Ubuntu 5.10...

In any case, I tried to move the image repository to a CIFS-mounted drive. When I then tried to start digikam, it wouldn't start at all. From the command line, it appeared to start, but it just hung until I killed it.

So, does this mean that digikam doesn't work for image repositories that are not located on a local disk? Sounds _very_ limiting to me...

[Havard Bjastad (havard-bjastad)]

CIFS problem caused by this? http://www.sqlite.org/cvstrac/tktview?tn=1751,33

[Rf-kde (rf-kde)]

I'm not shure if it's only a sqlite problem. But also when it is so I agree a message for the user is better than quietly do nothing or just crash.

Anyway, maybe I have a little more information which might help.

I tested with an nfs mount and also (the same album folder) with a samba share mounted with cifs. The behaviour of digikam is the same. I can't say if file locking (and that seems to be the problem with sqlite) is working with samba or not.

I can work with V. 0.8.x and 0.9b1 having the album on the network mount. Importing images from the camera works, creating album folder and adding comments or tags - no problem.

What's not working is ...

1. to enable the option "Search for new photos on startup" (don't know the exact wording)

This will bring up a box on startup with a progress bar which goes to 99% and that's it. Nothing happens. Starting digikiam in the shell gives no output. Interestingly this worked once with V.0.8.?. (By the way, would be nice to have an "update album" function to search for new photos.)

Disabling the option makes digikam work again.
~/.kde/share/config/digikamrc:
[General Settings]
Scan At Start=false

2. importing files or folder into the album.

This start a copy process with a normal kde copy box. The box does not change and stays at 0% forever. Surprisingly the files are copied into the right place.

It's said that nfs and sqlite doesn't work, but that's not true. Even digikam works. What's not working are the import function of digikam. This might be related to sqlite, I don't know. In my opinion, sqlite on an nfs share shouldn't make any difference when only one user access the db - it's just slower.
It would be nice if that get fixed in 0.9

[Rf-kde (rf-kde)]

One addition. When you get the message "The database could not be actualiced from old to new format" set "Scan At Start=false" as described and remove the file "digikam3.db-journal" from your album path. Now you can work again with the limitation that importing files doesn't work (as described in my previous post).

[Havard Bjastad (havard-bjastad)]

Since there's been no movement on this for months, I thought I'd move the pictures to another network disk (I need to access them from more than one machine). So i bought a WD NetCenter disk and mounted it using CIFS. Unfortunately, the result is the same. Does this mean digikam can only be used with pictures stored on a local disk?

http://bugs.kde.org/show_bug.cgi?id=121005 indicates that the digikam developers do not want to do anything about the situation :-(

[Tom Albers (tomalbers-deactivatedaccount)]

Bug 121005 does not say that. If there is a solution presented by sqlite it will probably be implemented.

You can use a compile time option to store the db in your home folder instead of near the album folder. If that's a solution for you use that. Although not supported by the developers.

[Havard-u (havard-u)]

I find it incredibly arrogant to just close this issue as RESOLVED, which reports a very real problem for a lot of users (see also https://bugs.kde.org/show_bug.cgi?id=137694). I have tried setting Scan At Start=false, but I get the same behavior nonetheless. Too bad we now have to find other applications for photo management, cause digikam is a fantastic tool for the job...

[Caulier-gilles-9 (caulier-gilles-9)]

Havard,

This file have been closed because there are a lots of report about this SQlite/NFS problem

Marcel, currently implement a new generic DB interface witch will can use others DB engine like MySQL for example, to use more than on album library path, etc...

Until now, we haven't work on DB but on others very imprtant part like color management, 16 bits color depth, RAW file format, IPTC, makernote GPS metadata support ect.

Later 0.9.2 release planed to June, we will work exclusivly to DB stuff...

Gilles Caulier

[Micron (microngust)]

=digiKam and CIFS/SAMBA/NFS Solution=

Here's a workaround that makes digiKam store pictures on a network folder and it's database on a local drive.

==Background==
When you specify that digiKam should store pictures on a network folder (CIFS/SAMBA or NFS), digiKam will hang. If you try restarting digiKam, there will be no visual feedback. This is a workaround that will allow you to have digiKam store pictures on a network folder.

==Configuration Cleanup==
First, if you've already run digiKam and it has hung (or done nothing) you must do the following to clean up the corrupt digiKam configuration:

1. Verify that digiKam is not still running. If it's running, kill it off. (The digiKam process may be running even if you don't see digiKam on your desktop. Use the "ps" and "kill" commands to verify and kill off the process, or, simply bring up KDE System Guard, find the digiKam process, and, kill it.)

2. Delete your digiKam config file, located at: ~/.kde/share/config/digikamrc

3. Go to the folder you specified as the "Albums Library Folder" and delete the two files that digiKam created: "digikam3.db" and "digikam3.db-journal".

==The Workaround==
Now you can re-configure digiKam from a fresh start as follows:

1. Start digiKam.

2. When prompted for the "Albums Library Folder", specify a local folder (eg ~/.digiKam).

3. Through Konqueror, navigate to a network folder where you want to store pictures. (I'll refer to this as your "network pictures folder".)

4. Create a symlink from the digikam3.db file, which digiKam created in your local "Albums Library Folder", to your network pictures folder.

5. In digiKam, go to the "Settings" menu and select "Configure digiKam ...".

6. In the "Configure - digiKam" dialog, select "Albums" and then change the "Album Library Path" to your network pictures folder.

==Conclusion==
Now digiKam should save pictures to your network pictures folder and it should save to the database on your local drive.

[Caulier-gilles-9 (caulier-gilles-9)]

You can take a look into this blog :

http://thoughtsonrails.wordpress.com/2007/03/03/digikam-albums-on-network-filesystem/

Gilles Caulier

[Fabien (fabien-ubuntu)]

Note: I have a small patch on my computer to be able to define another path for the library db. But, it's a bit dirty for the moment and it's a bit limited.

In fact, I added a "Album dbPath" entry in the configuration file that I read with Kconfig. It works pretty well except that I have in "kioslave/sqlitedb.cpp" to call explicitly the config file digikamrc (" KConfig config("digikamrc");") instead of the default inherited config name to avoid problems with kio_digikamalbum* :
if I don't do that, I have to replicate the config file for each kio_digikam* (kio_digikamalbumsrc, kio_digikamdatesrc, kio_digikamsearchrc, kio_digikamtagsrc , kio_digikamthumbnailrc).

I'll try to polish it a bit and post it here...

[Paul Abrahams (abrahams)]

I tried the workaround from #7 and it didn't work -- digikam gave me a message about being unable to convert the database to the new format. No idea what that's about.

I did find a different, not very satisfying workaround:

1. Move your pictures to a directory on the remote storage device, putting them in a directory called, say, /remdevice/Pictures.

2. Remove the digikamrc file and start up digikam again as suggested in #7.

3. Create a symlink from ~/Pictures/Remote_Albums to /remdevice/Pictures.

Now the pictures on the remote device are available, but are one level down from the top.

Really, all this shouldn't be necessary. At a minimum, digikam shouldn't hang when the Albums Library Folder is specified as being on a network device.

[Caulier-gilles-9 (caulier-gilles-9)]

>I tried the workaround from #7 and it didn't work -- digikam gave me a message >about being unable to convert the database to the new format. No idea what >that's about.

I have just reproduce the problem here in others conditions: the mount path which host your pictures and DB file is read only.

Gilles

[Paul Abrahams (abrahams)]

Re #11 -- that's 90% of the answer. Write permission for digikam3.db must be turned on for all users, not just for the owner. (The default is to turn it on for the owner in any case.) The problem arises because the owner of the pictures directory on the remote device is not the same as the owner of the local files.

I fixed the write permissions of ~/Pictures/digikam3.db and now digikam works just fine with pictures stored on my HP Mediavault (a Network Attached Storage device).

Many thanks, Gilles.

[Sod75-y (sod75-y)]

on kubuntu/edgy, digikam 0.9.1 I had this bug introduced by the following mysql patch, but the workaround as described in #12 ( give write perms to all ) solved it for me. everything still on nfs.

mysql-dfsg-5.0 (5.0.38-0ubuntu1.1) feisty-security; urgency=low

  * SECURITY UPDATE: denial of service via crafted IF clause
  * debian/patches/91_CVE-2007-2583.dpatch: fix sql/item_cmpfunc.cc to verify
    res is not NULL
  * SECURITY UPDATE: privilege escalation
  * debian/patches/91_CVE-2007-2691.dpatch: fix sql/sql_parse.cc to make sure
    DROP privileges are required when using RENAME TABLE statements
  * SECURITY UPDATE: denial of service via crafted authentication request
  * debian/patches/91_CVE-2007-3780.dpatch: fix sql/sql_parse.cc to not
    overflow a signed char
  * SECURITY UPDATE: privilege escalation via views
  * debian/patches/91_CVE-2007-3782.dpatch: fix sql/sql_prepare.cc and
    sql/sql_update.cc to properly verify access privileges to external tables
  * SECURITY UPDATE: warn on startup if root mysql account has a blank
    password. debian/mysql-server-5.0.mysql.init: supply 'reset-password' and
    check for blank password. Based on work by Soren Hansen.
  * References
    CVE-2007-2583
    CVE-2007-2691
    CVE-2007-3780
    CVE-2007-3782
    Launchpad #119075

 -- Jamie Strandboge <email address hidden> Wed, 3 Oct 2007 13:32:38 -0400

[Havard Bjastad (havard-bjastad)]

http://bugs.kde.org/show_bug.cgi?id=137694 has now been fixed upstream, can we please get this into the next Ubuntu release?

[Achim Bohnet (allee)]

digikam 0.10 is based on KDE4 and more or less a rewrite.
IMHO it's not something to consider for hardy. If nothing goes wrong
digikam 0.10 will be ready together for KDE 4.1 in Juli and there will be
backports, either officiall ones or in my repo.

Achim

[silicoid (ubuntuuniverse)]

If you still have an NFS filesystem try using the mount option nolock. This will lead to loclal locks only, so be sure to not work from two machines at the same time. I do not know if CIFS knows this option too.
Another option would be to move the database to a local filesystem (your home) and do an symbolic link. In this case the data is only available on one machine and has to be synced by you somehow.

This problem was discussed several times on the digicam mailinglist.
See also the digikam FAQ: http://www.digikam.org/?q=node/219

[Fabien (fabien-ubuntu)]

Hi,

Some people here could be interested in testing the following patch with 0.9.4svn version :
http://mail.kde.org/pipermail/digikam-devel/2008-July/019511.html

This makes sqlite use .lock files for locking the database which is supported on all platforms and filesystems. Use at your own risk... Works for me :)

[Fabien (fabien-ubuntu)]

Hi,

Some people here could be interested in testing the following patch with 0.9.4svn version :
http://mail.kde.org/pipermail/digikam-devel/2008-July/019511.html

This makes sqlite use .lock files for locking the database which is supported on all platforms and filesystems. Use at your own risk... Works for me :)

[Peter Soetens (peter-soetens)]

I'm desperately waiting for a fix of this kind in Ubuntu. I bought a NAS to specifically store my pictures on, and then digikam refused to work with it. In case dot lock files have a performance issue for local filesystems, the sqlite implementation could try to find out if unix locking is supported on the album filesystem and if not, use dot lock files as a fallback option. But maybe the Linux caching makes this irrelevant...

The solution of bug http://bugs.kde.org/show_bug.cgi?id=137694 does not please me. I want to have my tags database on different computers as well.

Peter

[Luka Renko (lure)]

This is partially addressed in KDE4 version of digikam (0.10.0), which is now in Jaunty (and you can try it on Intrepid from digikam-experimental PPA). Is the following implementation acceptable for you:
http://bugs.kde.org/show_bug.cgi?id=137694#c13

[Havard Bjastad (havard-bjastad)]

Yes, for ME, that solution would be sufficient - and I could go back to using digikam (after waiting for 2 years)

[Luka Renko (lure)]

Closing as Fixed, as Digikam 0.10.0 (in Jaunty) provides better support for network shares.