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 > <[email protected]> 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. > <[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. _______________________________________________ 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.
