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
