[Digikam-devel] [spam detected by bogofilter] problems with digikam3.db into a nefs partition

Achim Bohnet ach at mpe.mpg.de
Tue Mar 6 23:34:47 CET 2007


On Monday, 5. March 2007, Fabien wrote:
> Hi,
> 
> Please, please, evaluate my proposal :
> http://bugs.kde.org/show_bug.cgi?id=107871#c6
> 
> <<
> I suggest to add 2 command-line options to start digikam.
> 
> * -f to to specify the full path to digikam3.db, or relative path from 
> the album directory
> 
> * directory as argument => this would be the album path digikam use
> 
> Eg:
> 
> 1) # digikam
> would behave like now. The 1st time, it will ask for an album path
> 
> 2) # digikam -f /path/to/digikam3.db
> would behave like now except it will use the specific path for the 
> database file
> 
> 3) # digikam /path/to/my/album
> digikam will use this directory as the album path, but won't override 
> default album path if there's already one
> 
> 4) # digikam -f /path/to/digikam3.db /path/to/my/album
> would combine 2) and 3)
>  >>
> 
> This would not only be a workaround for the nfs/samba locking problem, 
> but also a way to extend digiKam's usage :
> some people complain that they can only use one library which stores all 
> their pictures. They'd like to have a few libraries. There are also some 
>   people who'd like to access pictures on a read-only media (eg DVD). 
> Finally, some people would also like to open a specific directory which 
> contains pictures, like you can do with other tools.
> All these wishes could be mostly solved by this addon...

I agree with your points 1-4.   Nevertheless from user point of
view having a warning when pictures are on a remote file system, like:

	Your picture library is on a remote file system.
	The digikam's database can't be stored there. 
	Please spezify a local folder

		[Browse ...]    [Quit]

Is much more helpful.

Feel free to cut and paste to your bug report of post the bug# ;)

Achim

> Gilles Caulier wrote:
> > Yes, the sqlite/NFS problem is know since a long time (look the SQlite 
> > FAQ from sqlite web project page).
> >  
> > I think than there is no issue with SQlite implementation about NFS.
> >  
> > There is plan for the future to solve the problem :
> >  
> > 1/ add a "red" warning message in Album library path digiKam setting, 
> > like i have do with JPEG image saving settings. The message must be 
> > something like that : "Local path, not Remote path like NFS". Gerhard, 
> > it's easy to do. If you want to do it, just look how i have implemented 
> > the JPEG options widget here :
> >  
> > http://websvn.kde.org/trunk/extragear/graphics/digikam/libs/dimg/loaders/jpegsettings.cpp?revision=634175&view=markup 
> > <http://websvn.kde.org/trunk/extragear/graphics/digikam/libs/dimg/loaders/jpegsettings.cpp?revision=634175&view=markup>
> >  
> > 2/ there is already an option with .configure script to place the 
> > database file outside the Album repository (the digikam3.db file is 
> > place in local home directory). But i'm not sure if this option work 
> > properlly. I have personaly never used NFS with digiKam. Also this way 
> > require to compile by hand digiKam & co to just use NFS.
> >  
> > 3/ With the future QT4 port, we will create an universal DB frontend to 
> > use other DB backend than sqlite (like Amarock do).
> >  
> 
> --
> Fabien
> 
> _______________________________________________
> Digikam-devel mailing list
> Digikam-devel at kde.org
> https://mail.kde.org/mailman/listinfo/digikam-devel
> 
> 



-- 
  To me vi is Zen.  To use vi is to practice zen. Every command is
  a koan. Profound to the user, unintelligible to the uninitiated.
  You discover truth everytime you use it.
                                      -- reddy at lion.austin.ibm.com


More information about the Digikam-devel mailing list