[Digikam-users] How to keep digiKam from deleting image files

[Jean-François Rabasse]

On Mon, 24 Jun 2013, Elle Stone wrote:

> My point is all these images that were deleted by digiKam were
> read-only. I thought that protected the images from accidental
> deletion. A lot of people thing the same thing! IT DOESN'T.
> This is how Linux file permissions work.

A lot of people think the same thing, and also a lot of
developers.:-) Unix files access rights aim to protect users
data against other users, not against themselves. From the
moment you own, a file, a directory, you can do what you wish
with it, it's your stuff.

A correct file deletion implementation should first check file
status (the stat() or lstat() system calls) and if and only if
the write permission is set for the current user/owner should
effectively delete the file (the unlink() system call).

But very few software implementations are written that way and
respect files permissions. The only correct software I know,
from that point of view, is the GNU Linux 'rm' command. If you
try to remove one of your read-only protected file, the program
will check and ask you confirmation for removal. (Also with the
'rm -f' option, you specify force removal and ignore file
permissions.)

> Alas this issue obtains with any image management software,
> unless that software has the ability to disable the delete
> option. Anyone know of such a software?

Not only images management software, the Dolphin files browser
does the same. Most applications don't deal with low level
system functions and rather use environment libraries. E.g.
Digikam, Dolphin, and probably all KDE based applications,
don't delete files themselves but use a KDE library function,
KIO::del() And, too bad, this function is not correctly
implemented, ignores files permissions and issue a brutal system
unlink(). (Same behaviour as 'rm -f')

The wise philosophy would be to consider that from the moment
you use any data management (edition capable) software,
your data arrive into risky-land and you should be paranoiac.

And your suggestion (ability to disable delete option in a
software) is fine but won't protect you against other problems
or bugs. (Recently, Volker Henn reported images destructions
while doing batch rotations ! )

So, no way but always working with backups under hand,
and backups created before starting working. Thus, restoring a
previous state of a file will still remain possible.

Regards,

Jean-François



PS: a bit off-topic but there's a rock solid Unix way to protect
data, using read-only filesystems. It's kernel based implemented
and when a disk device is mounted read-only in your directories
tree, it's impossible to write, modify, delete anything,
even under the 'root' account.

Typical usage is to have images collections on an external USB
drive, mounted in the local drive tree, e.g. /usb/albums

Initial mount of the USB device :
     mount -o ro /dev/your-usb-device /usb/albums
Remounting in read-write mode, when needed :
     mount -o remount,rw /usb/albums
Remounting in read-only mode after modifications :
     mount -o remount,ro,noload /usb/albums

(The noload option is to be used with journalised filesystems as
ext3 or ext4.)

Also, one must su to root to run mount commands. This gives an
extra security level because it's not possible to remount
read-write from a keyboard typo.

Read-only mount is really secure; you the user, any application,
even root, won't be able to do any change. The major constraint
is to prevent fine control onto individual items. With files
permissions it's possible to set one or two files in read-only
mode. With a read-only filesystem it's all or nothing.

Security or flexibility...

As for me, this is the way I work. Having lost files in the past
made me a bit paranoiac:-)

My workflow looks like :

1. Copy new images from SD card to local drive, into a folder.

2. Do another copy from SD card into a folder on a USB drive,
temporarily in read-write mode, then switch back to read-only.
(Having two copies of the images, the SD card can be wiped for
next use.)

3. Work (images edition, metadata, etc.) on the local drive.

4. At some occasions, e.g. after a working session, remount the
USB drive read-write and do a sync from local folder, then back
to read-only mode.

The current state of USB collections is secured read-only.
And this allows all kind of tasks that don't need modifications,
folders browsing, copying images, doing searches, uploading to
web albums, etc., and images are protected from keyboard mistakes
or applications issues.
The risky state, read-write, occurs only at some rare occasions.