After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 715764 - share/sync photo library between machines
share/sync photo library between machines
Status: RESOLVED OBSOLETE
Product: shotwell
Classification: Other
Component: network-storage
unspecified
Other All
: Normal enhancement
: ---
Assigned To: Shotwell Maintainers
Shotwell Maintainers
Depends on:
Blocks:
 
 
Reported: 2010-01-19 07:06 UTC by Adam Dingle
Modified: 2021-05-19 11:38 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Charles Lindsay 2013-11-25 21:42:36 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 

Comment 1 lists 2014-12-19 11:35:13 UTC
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
Comment 2 Jim Nelson 2014-12-19 21:33:11 UTC
Thanks for the tip.  I went through and fixed that and many more.
Comment 3 Brian J. Murrell 2015-04-17 12:04:25 UTC
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?
Comment 4 GNOME Infrastructure Team 2021-05-19 11:38:38 UTC
-- 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.