[Digikam-users] Moving files outside digikam

[Jean-François Rabasse]

On 31/01/12 04:58, Ben Staude wrote:
> > Hi all,
> > 
> > is it safe to move files and/or folders around within the digiKam
> > root directory using bash, perl and the like? Do I get exactly the
> > same entries in the database as if I moved them around from within
> > digikam, or will there be additional "garbage" entries or duplicates
> > in the database that wouldn't exist when using digiKam for moving
> > files around? Will all metadata always survive such action (metadata
> > not saved to images)?

On Wed, 1 Feb 2012, Jim Householder wrote:
> Hi
> 
> I have on many occasions used a file manager to shift files from one
> album to another and delete files with no problems. Digikam appears to
> scan and accommodate changes when it starts.

Hello all,

From my personal experience I fully agree with Jim. The only minor
difference is that I don't "had on many occasions", but I "always" use a
files browser (Dolphin in my case) to organise my folders, and not
Digikam. Reason below(1)

And yes, upon next DK start and directories scan, DK reflects correctly
all changes.

To answer to Ben's question,
> > Will all metadata always survive such action

When I started working that way, Files browser + DK, I've had a look at
the DB schema and did some tests. It appears that DK uses two ways to
recognise an image:
- Image path and name (i.e. Folder/Subfolder/ImageFileName)
- An image file signature, uniqueHash field in the DB (looks like a hex
encoded MD5 digest).

So what ?
- After having moved/renamed images with a file browser and restarted
DK, at scan time DK will recognise the previous image from its
signature, and associated metadata, caption, tags, is kept and correct.

- After having edited an image, GIMP or other, outside DK, at scan time
if the folder and image names haven't been changed, metadata is still
valid and DK will recompute the new hash signature.

- After having moved or renamed, AND edited an image, DK will find it as
a new image (no more valid path, no more valid signature) and associated
metadata is lost. Of course, this if DK has been set in "Write metadata
to images files" mode off.

So, organisation with DK or files browser seems to be just a matter of
taste. The only care is to avoid moving + editing tagged or titled
images in the same processing session. (Another safe way is, obviously,
to first do all the organisation tasks, folders creations, images sets
split and move, etc., then start tagging tasks with DK on the final (or
close) albums structure.)

To the other Ben's question,
> > will there be additional "garbage" entries or duplicates in the
> > database

I cant' say. DK itself tends to leave some garbage entries across moves
and reorganisation. But I can't say if doing the job from an external
files browser may produce more, or just the same. However, it seems
useful to issue some "vacuum" commands on the DB at regular time
intervals.
I usually do that when I backup collections to an external USB drive.

Jean-François


(1) The reason why I always use a file browser rather than DK to
organise, move, copy, etc. comes from my personal definition of what is
an album. I have images files but also misc. extra files such as GPX
files from my GPS logger, some text files, comments, travel notes, etc.

And I wish to keep all this grouped with the pictures, in folders and
subfolders. From my point of view, an album is *all*, images files,
GPS tracks, travel notes, etc.
As DK ignores non images files at scan time, I can't handle all that
from the DK GUI via select + move actions. With a files browser I "see"
all my files, images or not images, and organisational work is far more
comfortable.