Version: 0.7.4 (using KDE 3.4.2 Level "b" , SUSE 10.0)
Compiler: Target: i586-suse-linux
OS: Linux (i686) release 2.6.13-15.8-default
When I choose an Album Path (Albumbibliothekspfad) on a network drive e.g.:
remote:/Server or remote:/smb-network/Server/Bilder, Digikam won't accept this path. It is not possible to close the Folder choose dialog. When I enter the path directly it adds my home directory:
I want to have my album on my mentwork, not on my local machine, but don't want to mount it.
Remote file system are not suitable with digiKam duing sqlite database problems. Take a look here :
Perhaps this problem will be solved in the future with next sqlite release, but not sure...
SVN commit 732444 by cgilles:
digiKam from trunk (KDE4) : First very important improvement here depending of the new Database interface/schema dedicaced to 0.10.0 release.
A new setting in album configuration page have been added to host the database file used by digiKam in a dedicaced place.
Before, the SQlite3 database file (digikam3.db) used by digiKam to store all image informations like Tags, Rating, Comments, Date, etc...
been store in the root album path. This solution introduce a big problem to use a root album on a network file system like NFS, because
SQLite3 do not like it (look here for more information : http://www.sqlite.org/faq.html#q7)
The only issue for this problem is to store the databse file in a separate place...
This is want mean than with this commit, digiKam can use a remote root album...
There is a screenshot of the new Album config page :
The next pending important change to do will to be able to drive more than one root album path with digiKam 0.10.0...
M +72 -58 digikam/albumsettings.cpp
M +3 -0 digikam/albumsettings.h
M +1 -1 digikam/digikamapp.cpp
M +3 -2 digikam/welcomepageview.cpp
M +72 -12 utilities/setup/setupgeneral.cpp
M +5 -1 utilities/setup/setupgeneral.h
WebSVN link: http://websvn.kde.org/?view=rev&revision=732444
SVN commit 733526 by cgilles:
digiKam from trunk (KDE4) : add Multiple Roots Album Path on setup.
With new database interface implemented by Marcel, digiKam can use more than one root album path as collection of images.
digiKam database file is now stored in a customized place wich still in local and can be different than roots album.
This is want mean than read only, remote repository, and disconnected repository are fully suported as well.
These collection types are able to use:
- Local drive.
- Remote drive (NFS/Samba) previously mounted in local file system.
- Removable drive as CD/DVD/USB hard drive.
Each collection set in configuaration dialog page can be named to be identified easily into Album GUI/Folder view.
There is a fresh screenshot of Collection Setup page at this url:
TODO: in album gui, and especially in album folder view, we need to add a better support of collections name.
M +434 -67 setupcollections.cpp
M +13 -1 setupcollections.h
WebSVN link: http://websvn.kde.org/?view=rev&revision=733526
I have closed this file because next digiKam 0.10.0 is now fully compatible with remote repository hosted by a network file system like NFS.
But setup config page do not allow to set a remote path using protocol + server name + path. This still must be configurable outside digikam (as an already mounted path).
I'm not sure than provide a way to use this way is right in digiKam. There are already a lots of tools outside digiKam to set properly an NFS server path to use in local. Why re-invent the wheel ?
Perhaps i'm wrong here. Let's me know.
In all case, the file http://bugs.kde.org/show_bug.cgi?id=146865 is certainly more generic and more adapted to continue this discussion. Right ?
Is it fixed?
Because on kubuntu gutsy, I have the same problem...
It's fixed with digiKam for KDE4 (future 0.10.0 release)
digiKam 0.9.x (KDE3) will not be fixed. this require a lots of database changes.
Some people here could be interested in testing the following patch with 0.9.4svn version :
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 :)