GNOME Bugzilla – Bug 511185
share photos among system users
Last modified: 2008-01-29 09:42:43 UTC
I would like to see an option to "share" your photos with other users on the system. My wife and I have separate logins so if I import the photos while logged in, she can't view them and vice versa. You can maintain 2 copies of the photos but that is a pain. It might even be nice to be able to share it across our LAN so if I'm on my laptop I can view photos that are on my desktop.
This is not something F-Spot can do. Set up a shared directory on your system with the appropriate permissions and then run f-spot with the -b and -p parameters set accordingly. If F-Spot doesn't set the proper permission on imported/modified files open a new bug.
Umm... i was under the impression that this was posted to the "new feature request" area. I know f-spot can't do this now but I would like to see it do it in the future.
hey Saturnino, no, maintaining 2 copies of the same images is definitely not an option. To share a f-spot db (and images) between users on the same computer, as Maxxer said, use the -p and -p flags wisely. Let's say you're running f-spot usually, your db is located at /home/you/.gnome2/photos.db and your photos are in /home/you/Photos/ You can run f-spot by just typing "f-spot" If your wife wants to share your db, she can do that by running "f-spot -p /home/you/Photos/ -b /home/you/.gnome2/photos.db". That /should/ work if you share the same group (if not, report a bug). Sharing over the LAN would be nice and it's definitely something we're thinking about, and this feature is already requested elsewhere.
Ah, thanks for elaborating. I checked the man page for f-spot and it didn't mention anything about -p and -b flags so I was pretty confused about what Maxxer was referring to. I'll give these flags a try tonight. Thanks for your help.
These flags are not described in the man page, but you can find information about them with the '--help' option.
Under Linux, the -b and -p options work, BUT: * both users must share the same group (no problem, here) * and you have to change the group ownership+permissions manually after each use. This is expected behavior for Unix, but is not really what an end-user is looking for. I am thinking about writing a little script which automates permission changes after each logout (/etc/gdm/PostSession), but I feel that this is a rather clumsy fix.
Why would you need to change the group ownership/permissions after each use? Also, I think it would be nice to see the option to specify your database in the preferences part of the GUI. You can select the import directory so I don't think it would be much effort to allow you to select the database file also.
Saturnino: >Why would you need to change the group ownership/permissions after each use? As I understand it, It is not strictly necessary to change the file ownership. We could give userB access to groupA. But in that case, userB would have access to all of userA's files, which I don't want. So, I create a new group, say, fspot, and let both userA and userB be part of that group. Thus, I have to change file *ownership* to 'fspot' after each use. But since by default Linux (or f-spot under Ubuntu Gutsy Linux, at least) creates new files and directories without write permission for the group, whatever method I choose above, I still have to change group *permissions* to 'g+w' after use. Of course, I might still be missing some point... > Also, I think it would be nice to see the option to specify your database in the preferences part of the GUI. I would love that, too... maybe even set up some kind of profiles...
Ahhh... I forgot to mention that with symbolic links you could probably avoid the use of -b and -p options, and with something like sshfs (or NFS) you could even share it easily over your LAN...
There's another issue wrapped up in all of this. If you have two users on different machines (i.e. sharing on a network drive) with different versions of sqlite, you could end up with one user making the database unreadable for the other user. An option to use a networked database, like mysql, would alleviate this issue. However, I don't know how easy/hard it would be to abstract the database code in f-spot out into a database neutral API with database plugins. Surely there must be a library that does this already, no?
That's a very valid point I haven't thought about. You would have to be really careful that no two users work with f-spot at the same time. Or you would really end up messing things up! If implementing a concurrent database would probably require a major code-overhaul, implementing a basic lock mechanism should be rather trivial. In such a scenario, a new copy of f-spot would simply refuse to start if someone else is already using that database. ...but I think I'm going rather off-topic...
The right thing, would be to use f-spot with gksudo or other method that allows you to run commands as an other user. But since this doesn't work right now, I filed a new bug about that: http://bugzilla.gnome.org/show_bug.cgi?id=512237