[Shotwell] Accessing an alternative database
Brian Candler
B.Candler at pobox.com
Sun Dec 26 22:11:48 UTC 2010
Hi,
I have a problem finding a good way to set up shotwell (testing using 0.7.2
under Ubuntu Lucid)
The scenario: both myself and my wife use the same computer at home. We have
our own home directories and logins. My wife has her own smartphone and I
want her to be able import into her own photo library without my assistance.
I would also like to be able to browse my wife's photo collection, and she
to be able to browse mine. But I don't want to import all her photos into
my collection (and vice versa), because any tagging, events, image
adjustment etc will have been lost.
Permissions are set up so that I have read-access to her home directory, and
vice versa. But unfortunately that's not good enough for shotwell:
$ shotwell -d ~caroline/.shotwell
** ERROR **: DatabaseTables.vala:55: execute_update_by_id: [8] attempt to write a readonly database
aborting...
Aborted
(Her photo collection *does* appear for about half a second before shotwell
terminates with the above error message)
So this gives a potential feature request 1: be able to browse a photo
collection even if you only have read access to it.
Having to start with a -d flag is also a bit manual, so potential feature
request 2 would be to add multiple libraries within the GUI, and be able to
switch between them (e.g. with a drop-down menu). Unfortunately I that
might open the floodgates to some more complex requests though, like being
able to add a photo from one collection into another.
Another option is to combine our collections, and make ~/.shotwell in both
home directories point to a common area. This would involve setting up a
group which is writeable to us both (ok), setting the setgid bit so that
files and subdirs inherit that group (ok), and getting shotwell to use the
correct umask. That last one doesn't appear to be well supported by
shotwell today (0.7.2 under Ubuntu Lucid). As a test, if I do
(umask 002; shotwell -d ~/.shotwelltest)
then the directories are created with group write permissions, but photo.db
is stil created mode 644.
$ ls -lR /u/home/brian/.shotwelltest/
/u/home/brian/.shotwelltest/:
total 12
drwxrwxr-x 2 brian brian 4096 2010-12-26 21:50 data
drwxrwxr-x 2 brian brian 4096 2010-12-26 21:50 mimics
drwxrwxr-x 4 brian brian 4096 2010-12-26 21:50 thumbs
/u/home/brian/.shotwelltest/data:
total 12
-rw-r--r-- 1 brian brian 10240 2010-12-26 21:50 photo.db
/u/home/brian/.shotwelltest/mimics:
total 0
/u/home/brian/.shotwelltest/thumbs:
total 8
drwxrwxr-x 2 brian brian 4096 2010-12-26 21:50 thumbs128
drwxrwxr-x 2 brian brian 4096 2010-12-26 21:50 thumbs360
/u/home/brian/.shotwelltest/thumbs/thumbs128:
total 0
/u/home/brian/.shotwelltest/thumbs/thumbs360:
total 0
I haven't tried testing anything else, e.g. what permissions thumbnail files
are written with, but I don't really want to be a trailblazer if nobody else
is using shotwell this way and it's likely to cause problems.
One day maybe all the metadata will be stored within the photos themselves
or on the filesystem(*), and sqlite3 would just become a cache of that data.
This is something I know has been discussed before, and may eventually
provide a solution, but I'd like to start using shotwell now.
We can just browse each other's Pictures directories using gthumb, but
that's painful given the YYYY/MM/DD directory structure which shotwell
imports to.
Any other suggestions?
Thanks,
Brian.
(*) I'd also like to sync my photo collection from my home PC to my laptop,
and have the metadata sync too. 'unison' handles file replication both ways
nicely, but independent updates to the sqlite3 database can't be resolved.
For now I can live with the photo database just being on the desktop.
More information about the Shotwell-list
mailing list