[Digikam-users] Digikam file management

[Geert Janssens]

On Thursday 30 July 2009, Markus Spring wrote:
> stefan at binaervarianz.de schrieb:
> > It would be a bit more to it than replacing/extending the copy mechanism.
> > Whenever you change a property of a hardlinked file, you have to ask
> > the user if he wants to change just the one file (and thereby create a
> > new independent copy) or alter all files. I don't know the
> > architecture of digikam, but I suppose this would mean a lot of places
> > where a routine like that needs to be implemented.
>
I was going to write a similar remark, but you beat me to it. :-)

> ok, I forgot to think about this field of problems.
> As directory-relateed properties I see last access, modification, access
> rights. These are kept synchronous with hardlinked files.
>
> I just tested and made a hardlink copy of a jpg file and then modified it
> with digikam's image editor. The result is as such:
>
> springm at denkbrett:~/Bilder/test$ ls -lisa farbkreis.jpg test.jpg
> 1744903131 220 -rw-rw-r-- 2 springm springm 221702 2008-11-22 22:59
> farbkreis.jpg 1744903131 220 -rw-rw-r-- 2 springm springm 221702 2008-11-22
> 22:59 test.jpg
>
> # now modifying the file test.jpg and saving it in the image editor
>
> springm at denkbrett:~/Bilder/test$ ls -lisa farbkreis.jpg test.jpg
> 1744903131 220 -rw-rw-r-- 1 springm springm 221702 2008-11-22 22:59
> farbkreis.jpg 1761442766  60 -rw-rw-r-- 1 springm springm  60691 2009-07-30
> 13:33 test.jpg springm at denkbrett:~/Bilder/test$
>
> obviously the image editor writes a new file, removes the original one and
> renames the new file to the original name. So at least in this respect we
> would not have any difficulties. For other operations this has to be
> tested.
>
This is interesting, but non-consistent. If the file being edited is 
hardlinked by other files, changing the original file should reflect this 
change in all files. That's how I would expect a link to behave. In fact, I 
tend to consider this a bug, given the link vs copy metaphors being used. 

Also this is not only about the image editor. You can change your hardlinked 
files with other editors, like the Gimp, Krita,... All these editors should 
exhibit the same behavior with hardlinked files or we're up for some major 
confusion.

> I think this is the behaviour that most users would expect: a copied file
> is a copy and treated separatedly from the original.
> But to avoid all troubles I could imagine to make this an 'expert option'
> and offer it additionally to the traditional copy method.
>
Indeed.

And quite honestly, I don't think it's digikam that should define how 
hardlinks should be treated. The scope of it is much wider than one image 
management tool.

I think it would better if this were defined and implemented at the desktop 
level (ie KDE/Gnome/Freedestkop.org in general). Digikam would then free to 
add this feature as defined by KDE/Freedesktop.org in a way that is consistent 
across applications.

> > It would be a major feature at least for the *nix systems nevertheless...
>
> Definitely!
>
> Markus
> _______________________________________________
> Digikam-users mailing list
> Digikam-users at kde.org
> https://mail.kde.org/mailman/listinfo/digikam-users