David T:
The two users are not allowed to use gnucash at the same time. The one who
sets the lock file is in control. If they auto save and remove the lock file,
user 2 can set a lock file and use the data, exclusively until they save and so
remove the lock file.
Yes, the memory info is all invalid if you discover a lock from another. The
gnucash process that discovers the data moved might just exec() to flush the
memory and reload from disk.
My suggestion is a lightweight solution exploiting the quiescent state of
gnucash files after a save. You can, of course, envision a server based multi
user app, but that is a huge change in code and architecture. Is a mini spare
tire worse than no spare tire, and only full sized spares are worth using?
The worst behavior I envision is that one user discovers the files have been
taken over when, after a save, they want to start a new modification. They
need to get told to try later, because the files are locked. Of course, they
could override, but they would know that transactions might have been lost. If
another user is actually modifying the data and you override the lock, then you
have a problem. This feature is not intended to support a swarm of data entry
users, just for one user/few users moving from one computer to another.
We already have data vulnerabilities every time we override the lock file, but
with this feature auto save would be removing the lock file more often, so
overriding would happen far less, just on unsaved data with either app crashes
or reboots without a save. Does gnucash save when it get asked to terminate by
a system reboot?
Best,
David P
On Thursday, July 16, 2026 at 10:46:41 PM EDT, David T.
<[email protected]> wrote:
I heartily agree with David C.
Some additional points:
* GnuCash loads the entire xml file into memory at startup. It then works off
this internal copy, so all your changes occur there. Thus, a "quiescent" file
at the operating system could have large numbers of changes locally. As the
changes pile up locally, you increase the chance of data corruption.
* This solution utterly breaks down if two users happen to work in the same
transaction set. *Whose* changes in that situation take priority? Just testing
for file age (as flawed as that is, as Jim has pointed out) doesn't address
this rather significant problem.
* Developers have already created applications that manage these issues in a
far more nuanced and principled way. It's a significant concern for database
applications, which is why the GnuCash roadmap is directed that way. Why
attempt a home grown solution to a problem that has already been solved?
I'm sure there are other points I was going to make, but I'll leave it at this:
First, this is an open source project, and you are encouraged to open the
source and test your feature out by coding it in, testing it out, and
submitting it as a pull request.
Second, the most fundamental feature of any accounting program is its ability
to preserve data integrity, and undermining that is playing with fire.
David T.
On July 17, 2026 6:21:25 AM GMT+05:30, 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.
-- Jimgnucash-user mailing list
[email protected]
To update your subscription preferences or to unsubscribe:
https://lists.gnucash.org/mailman/listinfo/gnucash-userPlease remember to CC
this list on all your replies.
You can do this by using Reply-To-List or Reply-All.
_______________________________________________
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.
