David C:
The idea of a database multi user gnucash begs the question of where the
database files and servers run! If the database files are on shared cloud
disks, the problems are just moved to the database engine! If the database is
set up in the internet, on a server, or in the cloud entirely, then many
gnucash clients can connect to it and try to stay out of each other's hair, but
that is a big deal, like if two sessions are working in the same account, do
the actions of one immediately change the screen of the other! What if the
changes are up or down screen? I guess the totals would have to change for the
Southern user!
A side issue arises in the gnucash state when a transactions is added or
modified but not committed by going to another line or whatever. I am not sure
an auto save can include them, so they can be lost, and if such are in process,
removing the lock does create a data loss/corruption problem. No free lunch!
:D
Best,
David P
On Thursday, July 16, 2026 at 08:51:38 PM EDT, David Carlson
<[email protected]> wrote:
I think that this would open up the program to another way to corrupt the
data. The developers are already working toward a goal of making the program
truly fit in a multi-user database format. I would prefer trying to accelerate
progress to that goal.
On Thu, Jul 16, 2026 at 3:47 PM David G. Pickett via gnucash-user
<[email protected]> wrote:
The check is just based on a boolean variable set when the lock file is
removed. If set, check for a lock file of another user and then check if the
primary file is now different. Checking a boolean is the cost of a 1 byte
fetch.
Other users arriving can set a lock file and create a new version as usual, but
of course will set the boolean and remove that lock file after creating a new
primary version with a save.
I suppose that the next modifier of the data should write a new version, as
now, not rewrite the primary version, even if they authored the current primary
version with a save. We don't want to get into a race condition. There might
need to more checking of the lock file, moving that check to where a
modification has occurred.
The general idea is that, with timed auto save, the file is quiescent a lot of
the time, and the lock file is not necessary. If you reboot without giving
gnucash a normal termination, you will generally have to accept that the lock
file is irrelevant, although for no-timed-save people, it may indicate a loss
of some transactions. Maybe timed save should be mandatory, and only the
duration configured?
On Thursday, July 16, 2026 at 03:49:35 PM EDT, Jim Passmore
<[email protected]> wrote:
On Wed, Jul 15, 2026 at 11:34 AM David G. Pickett via gnucash-user
<[email protected]> wrote:
It occurred to me that, once a save has been completed, gnucash could delete
the lock file. This would allow either another user of networked files or a
botch run for finance quotes to update the file. If the running original
gnucash goes to modify his memory or display a new page or report, a flag can
tell it that it deleted the lock, and so check the age of the file
Mulling it over...* How often should it check for the presence of the lock
file? Seems like checking the file system before every action could drag down
responsiveness. (And if too infrequently, and you'll make a change not knowing
the lock file has been created.)* When checking file "age" I assume it would
use a time stamp? What happens if the different computers don't have their
clocks synchronized? I've even had time stamp craziness on a single computer
when dual-booting 2 OS's...one assumes the time on the BIOS clock was local,
and the other assumes BIOS is UTC, so they were hours off.
-- Jim
_______________________________________________
gnucash-user mailing list
[email protected]
To update your subscription preferences or to unsubscribe:
https://lists.gnucash.org/mailman/listinfo/gnucash-user
-----
Please remember to CC this list on all your replies.
You can do this by using Reply-To-List or Reply-All.
--
David Carlson
_______________________________________________
gnucash-user mailing list
[email protected]
To update your subscription preferences or to unsubscribe:
https://lists.gnucash.org/mailman/listinfo/gnucash-user
-----
Please remember to CC this list on all your replies.
You can do this by using Reply-To-List or Reply-All.
