* Owen Mays <r.owen.m...@gmail.com> [12-14-19 17:03]: > 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
to edit files on more than one computer, it is very important to follow a strict regimen. network access your library and files being careful to only edit from one box at a time (easy to just use seat) or, utilize library = :memory: on the less utilized box making sure to save xmp files and import the edited files on the main box. this will keep your library up to date. I utilize both of these methods one time or another successfully. -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri Photos: http://wahoo.no-ip.org/piwigo paka @ IRCnet freenode ___________________________________________________________________________ darktable developer mailing list to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org
