Bruce, Thanks for the suggestion. Unfortunately it looks like that doesn't do what I'm looking for. Edits made on one computer don't show up on the other computer (I think it's because they are only sharing the photo files, not the library database).
Here's what I tried: Mount remote disk over sshfs. Select images. -> Make local copy. Edit image. "Resync local copies" When I open darktable on the other computer, those edits are nowhere to be seen, even if I request to "resync local copies." Does it matter how I have the remote directory mounted (using sshfs)? Is darktable attempting to detect whether storage is remote (NFS or SAMBA)? Thanks, Owen On Sat, Dec 14, 2019 at 12:29 PM Bruce Williams <stu...@audio2u.com> wrote: > Owen, > Have you looked at using the "local copies" feature? > That might be a safer alternative. > Just a thought. > Cheers, > Bruce Williams. > > ---------- Forwarded message --------- > From: Owen Mays <r.owen.m...@gmail.com> > Date: Sun., 15 Dec. 2019, 05:03 > Subject: Re: [darktable-dev] Database lock file seems too lenient > To: Sturm Flut <sturmf...@lieberbiber.de> > Cc: <darktable-dev@lists.darktable.org> > > > Hi Simon, > > Thanks for the response. I have a couple follow-up questions: > > 1) Why go to the trouble of adding hostname to PID in the lock file, why > not just check for existence of the lock file and treat that as evidence > that the database is open? It looks like many lines of code have been > written in database.c dedicated to finding an excuse to ignore the lock > file :-) (by checking for a running process, etc). > > 2) Since sharing the library is not recommended, is there a recommended > way to have one computer be aware of edits made on/by another computer? The > problem I'm trying to solve is: my photos live on my laptop and are usually > imported and edited there. For large jobs, I would like to be able to do > processing on my desktop, which has a GPU. My current solution is to mount > my laptop harddrive on the desktop via sshfs and point both darktable > instances to a library file in the shared folder. > > 3) Is there any risk to the database in doing this, provided I avoid > having multiple darktable instances accessing the database at once? (For > instance, the bash script I have that launches darktable and points it at > the shared folder could also check for the existence of the lockfile and > respect it). > > Thanks, > Owen > > On Sat, Dec 14, 2019 at 3:08 AM Sturm Flut <sturmf...@lieberbiber.de> > wrote: > >> Hi Owen, >> >> the locking mechanism could probably be extended to also include the >> hostname in the lockfile. >> >> The problem with putting SQLite databases on a network share is that >> it's discouraged by SQLite [1] to begin with because too many things can >> go wrong. If darktable's locking mechanism fails for any reason, you >> might end up with two darktable instances on two difference machines >> accessing your database and corrupting it. >> >> cheers, >> Simon >> >> >> [1] https://www.sqlite.org/faq.html#q5 >> >> >> On 14.12.19 09:42, Owen Mays wrote: >> > Hello Darktable Devs, >> > >> > First of all, thanks for a fantastic program! >> > >> > I'm attempting to share a darktable library between two computers >> (using >> > the same network storage), and I'm concerned about accidentally >> > corrupting the database. Darktable creates a lock file, but when I >> > launch darktable on the second computer, it just overwrites the lock >> file. >> > >> > It appears this is due to logic in the database.c file that checks >> > whether the PID in the lockfile belongs to an active process. Because >> > the lockfile was created by a process on another computer, darktable >> > thinks the lockfile is stale and overwrites it. >> > >> > Is there a reason the lockfile is not more strict? Why go to the effort >> > of checking the PID, why not assume the lockfile means a lock, and if >> > it's stale, leave it to the user to resolve? >> > >> > I can create a bash script wrapper to launch darktable that will first >> > check for the lockfile, but I'd like to understand the design decision. >> > >> > Thanks, >> > Owen >> > >> > >> ___________________________________________________________________________ >> > darktable developer mailing list to unsubscribe send a mail to >> > darktable-dev+unsubscr...@lists.darktable.org >> > > ___________________________________________________________________________ > darktable developer mailing list to unsubscribe send a mail to > darktable-dev+unsubscr...@lists.darktable.org > > ___________________________________________________________________________ > darktable developer mailing list to unsubscribe send a mail to > darktable-dev+unsubscr...@lists.darktable.org > ___________________________________________________________________________ darktable developer mailing list to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org
