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.
