[GNC] Lightweight multi-user enhancement suggestion

[Jim Passmore]

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 <dgpickett at aol.com> 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 <
> kalpesh.patel at usa.net> 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 <david.carlson.417 at gmail.com>
> Sent: Thursday, July 16, 2026 8:51 PM
> To: David G. Pickett <dgpickett at aol.com>
> Cc: Jim Passmore <jim at passmore4.com>; Gnucash Users <
> gnucash-user at gnucash.org>
> 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 <
> 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.
> > -- Jim
> >
> >
> > _______________________________________________
> > 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.
> >
>
>
> --
> David Carlson
>
>
>