[Digikam-users] remote digikam acces to server

Jean-François Rabasse jean-francois.rabasse at wanadoo.fr
Sun Jan 27 23:08:31 GMT 2013


Hello,

A few comments about this topic and the more general issue of non
local (local disk) collections data, often raised on this list.

First, to answer to Martin :

On Sun, 27 Jan 2013, Martin (KDE) wrote:

> Ist sshfs required? If not, did you try smb and/or NFS for this? I use
> NFS for central photo storage since about 6 years ago.

You're right, NFS can be a good solution for non local images storage
but NFS restricts to a local network. You can use NFS at home, if your
desktop PC is connected to a LAN server, you can't use NFS if your
storage is on an Internet server (e.g. ako web hoster or cloud provider.)
I use sshfs too, to access data on my web hosting workspace, NFS would
be impossible.

> To your problem: The path to your collection is stored in the database
> (afaik).

Pathname is stored in the DB, sometimes, not always, cf. below.

> Unless you use two different databases this is expected. Why do
> you use mysql instead of the local sqlite db?

Dominique will reply, but I guess he runs Digikam instances on two PC,
called PC1 and PC2, and wishes to have one and only one database.
So a MySQL solution, installed on the common server. SQLite3 can be
used only on local disks.


On Sun, 27 Jan 2013, Dominique Bernardi wrote:

> Good morning everybody,
> For some times I'm looking for an answer about my problem, without any, so
> I try this newsgroup. Hope someone could solve it.
>
> I move all my pics files to a server, and want to acess to it with 2
> client using sshfs, I configure it using http://userbase.kde.org/Digikam/
> Manage_Photos_from_Multiple_digiKam_Installations
> I complete this by installing on the server Mysql following instructions
> in http://userbase.kde.org/Digikam/Using_digiKam_with_MySQL.
> Til' here everything look ok except that :
> I connect with PC1 to server it does the job great, I close Pc1, unmount
> the sshfs point, start PC2, mount the sshfs point, start digikam wich ask
> me to look in /home/PC1/mountpoint_sshfs.
> The problem is reversible. if in PC2 I force it to import from the good
> directory. When i will close and start PC1, he will ask me to look in /
> home/PC2/mountpoint_sshfs.

Just a question, Dominique, when you write « /home/PC1/mountpoint_sshfs »
and « /home/PC1/mountpoint_sshfs », is it a symbolic notation meaning
« the sshfs mount point of PC1, resp. PC2 », or is it two different
pathnames ?

Digikam identifies images collections by pathname OR by physical devices
identifier, with - as far I could see - a preference for physical ID
(UUID identifiers). And more, DK seems to use (and store in the database)
pathnames only when it can't discover a physical device UUID.

I have similar problems, using two machines and one database (I do syncs
from one to the other). On both machines, I always have my collection
available under a start point directory, /data/images
On one machine, a laptop, the info is stored in the database by disk
UUID, e.g. if I go into my DB :
  SELECT * FROM AlbumRoots;
  1|Albums|0|1|volumeid:?uuid=9b8bd360-3058-4265-8e4c-019d2014efd4|/albums

(the UUID is my /data disk partition)

and on the machine, a desktop, the info is stored by pathname :
  SELECT * FROM AlbumRoots;
  1|Albums|0|1|volumeid:?path=%2Fdata%2Falbums|/

so, the path name of the mount point.
And the reason is that DK can't get an UUID because the device is not
a physical disk but a software RAID 1 mapped system.
The consequence is that mirroring my database from one machine to the
other one breaks the AlbumRoot !
Even if I « see » my images folders always under /data/images

For your problem, Dominique, my suggestion would be first that you
have a look at the way Digikam tags your folder(s).
Just connect to your DB and issue :
  SELECT * FROM AlbumRoots;

You'll probably see a tag by pathname, because a mounted SSHFS is a
device mapped software driver, not a physical mass storage device,
so an UUID has no effective meaning.
(Probably the same problem as with any software base mounted system,
SSHFS but also NFS, LVM, DMRAID, and now possible encrypted disks
partitions, Truecrypt or dm-crypt/LUKS. (I have encrypted drives,
LUKS containers can be assigned a UUID, Truecrypt containers can't))

Second, ensure you use exactly the same pathname on your two machines,
/home/sshfs-mount
If you volume id (in the database) is by pathname, you should get the
same things at the same place.

Hope this helps,
Regards,
Jean-François


PS: I really think this volume identification issue should be rethought
in a future. For Linux environments it's a recurrent source of problems.
The Unix philosophy was, 40 years ago, to have an application level
view of data as of one unique directories tree, starting from /, and
to forget all hardware related issues. Sub drivers, block devices
layer, and the mount mechanisme are here to forget the physical things.
An application should not have to deal with system implementation and
local drive, NFS mounted drive, SSHFS mounted drive, etc.
Juste see pathnames. It's up to the user to have expected things mounted
at the expected place.

And this, even for removable media, such as USB drives. I use several
USB drives with exact copies of my images (default USB drive, backup USB
drive, travels USB drive) and even though I always mount my drives
partitions at the same place, with the UUID mechanism Digikam doesn't
recognize my collections and I have to rebuild/reconnect when I don't use
the same drive as the previous time.

Also, in a future I think the « all on local disk » model will become
obsolete with the increasing use of LAN storage solutions, USB drives,
remote storage (via sshfs), cloud clients, etc.
In the last 12 months, I've started a big reorganisation of all my data,
images collection and other things, and I know have only 15 to 20% of
my images on local disk, no more. And I've noticed that my use of DK
has fallen to 15 to 20% of my use in the previous years.

Perhaps the remote images, offline collections, etc., issue could be
worth feedback and wishlists, for the near future.


More information about the Digikam-users mailing list