[Digikam-users] Digikam file management

[Markus Spring]

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.
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.

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.

> It would be a major feature at least for the *nix systems nevertheless...
Definitely!

Markus