I guess you do not understand, but discussion is good. How does one corrupt
the data? By a race condition? By ignoring a lock file? This might be a much
more infrequent situation that people take more seriously. The lock file might
be enhanced to say who wrote it when from where, as well, so the warning dialog
could be more informative.
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.
