Here we go again. The shared photo repository problem again. I have a shared repository into which many users can import photos. They should all be able to see and edit all photos in the repository. I can control group inheritance so that all photos are in the same group with the setgid bit on directories. What I cannot control within the filesystem/directory tree is umask however. Of course I don't want to change these users' general use default umask to allow group write permissions to all files they create, so, yes, I could create a wrapper script set a group-write permissive umask before starting f-spot but now I have to change everyone's desktop environment to make this change and remove the default f-spot launcher. Additionally, a user might want to keep a private photo repository and not have group writable photos in that, so always setting a group permissive umask before calling f-spot is not really the right solution either. What ISTM is the right solution is to have f-spot set the umask itself before importing photos. The UI could be a simple as showing what permission bits will be set in the import UI. A more complex (and complete UI) would be to store a mapping of umask-to-repository and dynamically changing the umask based on which repository the user imports into. This seems to further validate my thoughts that f-spot should keep the photos.db in a "per repository" fashion rather than the per-user mode that it currently. Obviously with per-repository databases, each user can still have their own personal repository and database, but per-repository databases furthers the "shared" use-case without hampering the per-user use case. Thots? b.
Attachment:
signature.asc
Description: This is a digitally signed message part