Bug 121005

This is a sqlite problem. Nothing we can do.

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

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

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).

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...

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

=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.

You can take a look into this blog :

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

Gilles Caulier

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...

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.

>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

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.

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 <jamie@ubuntu.com>  Wed,  3 Oct 2007 13:32:38 -0400

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 :)