Source code is at https://github.com/GnuCash/gnucash
Once implemented, I volunteer to help test if you can build Linux Flatpak or Mac versions (not running Windows). -- *Jim * On Fri, Jul 17, 2026 at 12:53 PM David G. Pickett <[email protected]> wrote: > Kalpesh: > > My suggestion will teach them, with lock files and messages if not by > normal documentation, that they cannot use it that way! > > I am familiar with callbacks, but in a multiuser system, I suppose > callbacks might need to flow between users! A remote common RDBMS might > not support that, so gnucash might need to become cloud/server based except > for clients for entry and display. Still no free lunch! :D > > Best, > > David P > > On Friday, July 17, 2026 at 06:00:13 AM EDT, Kalpesh Patel < > [email protected]> wrote: > > > I don’t think multi-user is trivial to implement. Especially with > something like this, everyone is going to jump on it and think that it has > full fledge capabilities when it doesn't. > > In multi-user a robust controller is going to be needed that serializes in > coming updates requests for data and then keeps track to perform call backs > to refresh. > > -----Original Message----- > From: David Carlson <[email protected]> > Sent: Thursday, July 16, 2026 8:51 PM > To: David G. Pickett <[email protected]> > Cc: Jim Passmore <[email protected]>; Gnucash Users < > [email protected]> > Subject: Re: [GNC] Lightweight multi-user enhancement suggestion > > 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.
