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
