[GNC] Lightweight multi-user enhancement suggestion

[Patrick James]

This basic "it's very easy" discussion has gotten very difficult.


> On 07/17/2026 9:37 AM PDT David G. Pickett via gnucash-user <gnucash-user at gnucash.org> wrote:
> 
>  
> 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. <sunfish62 at yahoo.com> 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 <david.carlson.417 at gmail.com> 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 <
> gnucash-user at gnucash.org> 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 <
> jim at passmore4.com> wrote:
> 
> 
> On Wed, Jul 15, 2026 at 11:34 AM David G. Pickett via gnucash-user <
> gnucash-user at gnucash.org> 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
> gnucash-user at gnucash.org
> 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
> gnucash-user at gnucash.org
> 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.