Version: 0.8.0 (using KDE 3.5.0 Level "a" , SUSE 10.0 UNSUPPORTED) Compiler: Target: i586-suse-linux OS: Linux (i686) release 2.6.13-15.7-default The permissions on the digikam3.db are by default 644. If you share a picture tree within your familiy, e.g. /data/pictures, and you are not the person who created the tree, digikam does not update the db or create new thumbs. This leads to the misunderstanding that digikam is not working properly, as it does not show newly downloaded pictures in the appropriate folders (althugh they are downloaded). Proper default permissions would be 666, or to be set by a dialog.
Well, I really don't think, a proper default permission should be 666.
I'm open for other suggestions. The issue is that digikam cant currently share a photo directory between users, which leads to improper results. If digikam shall be a roduct for end-users, the team should find a solution for this (664 could also be a solution ;-)
This is the global setting of your system. It is not up to digiKam to fix this to a certain setting. You can change the permission manually if you want and it will stay that way after that.
No, my global setting for newly created objects is 664 (via an entry in /etc/profile.local). This is obviuosly overruled by digicam. I still feel that this is an unnecessary difficulty for unexperienced users. If you dont want to fix it, you should at least mention it in the documentation.
"I am reluctant to change the file creation mask from 0644 to 0666 due to security concerns. If you really want the database to have 0666 permissions, you can either do a chmod() after the database is created, or create the database yourself (leaving the file empty) with any permissions you want prior to opening it with SQLite." If you think, the docs have to be changed, send a patch corresponding patch.
Hi, AFAIK digikam supports two running instances of digikam of the same user (2nd one with readonly access). On first look this looks similar/ identical to two instances started from different accounts. Technical reason that this is different may be o ~kde/share/config/digikam* are different for different users o looking of digikam3.db that ensures that second instance gets only readonly access is accuount specific implemented So if no technical problem (beside digikam using 644) exists. I think the bugreport, as a wishlist, is valid and should stay open: digikam should honour the default umask setting. Achim P.S. here the result of a quick test in a fresh user account: umask 002 digikam & Pictures/ ==> 775 Pictures/digikam3.db ==> 644 Pictures/SubDir ==> 755 Picutres/Subdir/d-and-d.png ==> 644 editing with IE and use 'Save as' preserves permisions. If orig image was 644 or 664 saved-as image has the same.
Achim, thanks for your comments. I trust you got it right that it was not the issue of two instances of digikam running parallel. In this case an effective lock mechanism is required. I also share the general view re. security. But to my understanding digikam is not a mission-critical part of the system. I feel the usability aspect should be more emphasized - esp. for those people coming from the non-Linux world. So if you share a picture tree e.g. within the family most people will not be aware of these access restrictions. Therefor a balanced view on 'security' is required. Anyway, I'm fine in extending the documentation on that topic - if someone points me the to the where and how. Cheers Axel
I ran exactly in the same issue today, and I had to use "strace digikam" to find the problem of rights. I do agree setting the rights to 666 is not the right thing to do, but digikam should trap the problem and display a message to user saying something like "I don't have the rights on this file : fix your setup". My current setup /home/david => me /home/nancy => my wife /home/commun => owned by david.commun I've got a cron that periodically updates the owner (but not the rights) to david.commun so that both of us can access the files. /home/commun/photo/digikam3.db was : $> ls -al digikam3.db -rw-r--r-- 1 david commun 402432 jan 26 20:20 digikam3.db When using digikam on wy wife's account to create a new album, here what happened : - digikam successfully created the new dir - the new dir briefly showed up in the left "album" panel - then as there is no rights on .db, digikam made the album disappear without any explanation Hope it can be "fixed". Keep the good work !
I reopen, maybe the maintainers can turn this into an enhancement. Thanks!
Sorry, no. This was a WONTFIX, so don't reopen it unless you're going to do the work and send the patch.