GNOME Bugzilla – Bug 715764
share/sync photo library between machines
Last modified: 2021-05-19 11:38:38 UTC
---- Reported by adam@yorba.org 2010-01-19 11:06:00 -0800 ---- Original Redmine bug id: 1292 Original URL: http://redmine.yorba.org/issues/1292 Searchable id: yorba-bug-1292 Original author: Adam Dingle Original description: Several users have asked for the ability to share/sync a photo library between machines. One possible approach would be to use CouchDB; we should investigate more. Related issues: related to shotwell - Feature #6845: Prevent Concurrent Access to Shotwell Database File (Open) ---- Additional Comments From shotwell-maint@gnome.bugs 2013-04-22 15:35:00 -0700 ---- ### History #### #1 Updated by Adam Dingle over 3 years ago * **Subject** changed from _sync photo library between machines_ to _share/sync photo library between machines_ #### #2 Updated by Take - about 3 years ago Bump on this one, and an mailing list thread, which has some ideas about implementations: http://lists.yorba.org/pipermail/shotwell/2010-September/000952.html #### #3 Updated by Joseph - almost 3 years ago In the meantime what about adding a warning if someone does try to open it up over ssh? Maybe checking for SSH_CLIENT or SSH_CONNECTION environment variables on startup? #### #4 Updated by Adam Dingle almost 3 years ago Well, the behavior that users mostly do to get in trouble today is to put their Shotwell database on a network drive. When they run in that situation, I think that SSH_CLIENT and SSH_CONNECTION won't typically be set, so I don't think this check would actually prevent most users from shooting themselves in the foot. #### #5 Updated by Joseph - almost 3 years ago So the appropriate check would be for the .shotwell being on a local filesystem? #### #6 Updated by Adam Dingle almost 3 years ago Well, that depends what you mean by 'local'. Some users might reasonably want to put their Shotwell database directory on an external hard drive. But I think it's probably a bad idea today to have the .shotwell directory on a network drive, so we could consider warning users in that situation. #### #7 Updated by Mateusz Loskot over 2 years ago In my opinion the FAQ Can I access a Shotwell library across a network, possibly from multiple machines? is misleading and should be split in two. One thing is ability to access photos library over network, from NAS share mounted using SMB or NFS protocols. A different thing, however, is synchronisation between machines (it would be conceptually similar to a distributed version control system like Git but for media files). Now, the answer given is that it's “not recommended†because “Shotwell was not designed to support this use caseâ€. What is not recommended? What use case is not supported? Is it accessing photos from NAS **or** synchronisation between machines **or** both? #### #8 Updated by Lucas Beeler over 2 years ago Hi mloskot, Having two computers (or two user accounts on the same computer) use the same Shotwell database is what is not recommended. Hope that clears things up. Lucas #### #9 Updated by Mateusz Loskot over 2 years ago Hi Lucas, Yes, it clears things up I believe. So, single-user access across network should be kosher. Mat #### #10 Updated by Bastian - over 2 years ago Hi, as an option for the short term could be a solution a lock file, like it is done by Thunderbird. Then only a single user can acces the database, and any other user gets rejected. This should be easyer to implement then a new database and it is a prevention againt databasecorruption if a user uses it on a share and isn't aware of the problem. Bastian #### #11 Updated by Adam Dingle over 1 year ago * **Priority** changed from _Low_ to _Normal_ #### #12 Updated by jcat _ over 1 year ago Can anyone tell me if this is likely to make any progress in the near future? A simple lock file alongside the DB would suffice to start off with, even non- concurrent multi-user support would be more than a step in the right direction. Many thanks. #### #13 Updated by Adam Dingle over 1 year ago We have no plans at the moment to work on this for the next release (0.13), only because we have a small team and other issues are more pressing. I agree that a simple lock file could be a reasonable idea here. If someone wants to submit a patch that implements that we'd certainly consider taking it. #### #14 Updated by jcat _ over 1 year ago Thanks for the info - I appreciate it. Given this is not coming in 0.13, I'll proceed to create my own wrapper script to implement this locally for the moment. I'm not enough of a programmer to add this feature to the application, otherwise I would be glad to have a look :) Thanks again. #### #15 Updated by Damian Moore 7 months ago * **File** _1292_database_lock.diff_ added Hi, I'm new here but a long time Shotwell user and fan. This issue affects me as my girlfriend and I share a Shotwell data directory on a NAS. I have a patch for a simple lock file implementation that I'd like someone to code review. This is the first bit of Vala I've ever written, so please go easy on me! The patch is attached and can also be viewed here: https://github.com/damianmoore/shotwell/pull/1/files Also, I wasn't able to assign this ticket to myself so if someone could update it that would be good. #### #16 Updated by Lucas Beeler 7 months ago * **Category** set to _network-storage_ * **Status** changed from _Open_ to _Review_ @Damian: Thank you so much for the patch. The design intent of this ticket actually goes beyond mere file locking. This ticket is really about some kind of automated discovery and P2P protocol for sharing photos among instances of Shotwell on a LAN. I don't know if a lock file is something we want. Anyway, I'm going to change the status of this ticket to "Review" and discuss the patch with the rest of the team. Note that it might be a few days because one Shotwell team member is on holiday this week! Thanks again for the patch! #### #17 Updated by Lucas Beeler 7 months ago * **Status** changed from _Review_ to _Open_ @Damian: Since the patch you submitted isn't really within the intended scope of this ticket, I've created a new ticket for preventing concurrent access to a network-shared Shotwell database here: http://redmine.yorba.org/issues/6845. #### #18 Updated by Lucas Beeler 7 months ago * **File** deleted (<strike>_1292_database_lock.diff_</strike>) #### #19 Updated by Lucas Beeler 7 months ago @Damian: I've reviewed your patch on the new ticket I've created, as described below. --- Bug imported by chaz@yorba.org 2013-11-25 21:42 UTC --- This bug was previously known as _bug_ 1292 at http://redmine.yorba.org/show_bug.cgi?id=1292 Unknown version " in product shotwell. Setting version to "!unspecified". Unknown milestone "unknown in product shotwell. Setting to default milestone for this product, "---". Setting qa contact to the default for this product. This bug either had no qa contact or an invalid one. Resolution set on an open status. Dropping resolution
Now that Ticket 1292 has been moved here, perhaps the FAQ should be updated to point here instead. I had to search to find this bug. https://wiki.gnome.org/Apps/Shotwell/FAQ
Thanks for the tip. I went through and fixed that and many more.
Is the only problem here the concurrent access to a sqlite database? Couldn't this problem be entirely addressed by abstracting the database access so that different databases can be used in the backend, where one of the options is mysql/postgres, which would then allow safe concurrent access?
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/shotwell/-/issues/908.