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. >> -- 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. _______________________________________________ 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.
