I have successfully written a script that handles the latency issue with Dropbox. It uses Curl functions and json structures to pass information through Dropbox's API. The first thing it does is compare a hash of the file on Dropbox with a hash of the file on the local computer. If they are the same, then it attempts to move a token file in the Drobox cloud from a "Not in use" folder to an "In Use" folder. Once that token is there, no other user can attempt to access the file (assuming they're running the same script). If the hashes are different, the user is advised they are different and to wait until Dropbox syncs with his computer. The In Use/Not In Use token folders gets mirrored through normal Dropbox sync with identical folders on the local machines. But the check for "in Use" is always done in the cloud. The user with access rights then opens up the local file on his machine and goes to work. Once he's done, he closes the program and then moves the token file from the "In Use" folder to the "Not In Use" folder on his local machine (not the cloud). The data file and the In Use/Not in Use folders sync with Dropbox and it is only after that machine that just had access rights syncs with Dropbox that the token is available in the cloud to be grabbed by the next user. The next user goes through the same process. If he is successful at grabbing the token and the hash of his local data file equals the hash of the data file on Drobox, he/she is then able to access the data file.
I used this successfully for about 2 years with Quicken and so far it is working with GnuCash. I haven't put it in GitHub because I really don't know how to post a sanitized version there. My script has my Dropbox access keys, computer names, etc. But AI can be useful in writing such a script. Matt Newman Sent from Outlook<http://aka.ms/weboutlook> ________________________________ From: gnucash-user <[email protected]> on behalf of John Ralls <[email protected]> Sent: Tuesday, September 1, 2026 1:25 PM To: Patrick James <[email protected]> Cc: [email protected] <[email protected]> Subject: Re: [GNC] Risks of merging xml save files The only file-sharing mechanism I’d recommend is a shared directory on a local computer. Any remote-storage service like Dropbox or Google Drive has too much latency for the file locking mechanism to be effective. Jim’s right about git not being a good choice, but his illustration wasn’t great: You’ve already observed that the transaction count isn’t very important. A greater risk is that if you and your wife separately enter similar transactions a git merge might try to merge them into a singe transaction with only a few scattered lines like the id elements flagged as differences. The only safe way to modify a GnuCash data file is to use GnuCash’s API, either from C, Python, or Scheme. All of the data integrity checks are in GnuCash code. There are none in the SQL formats so it’s no safer to modify a SQL book than an XML one with external software. Regards, John Ralls > On Aug 31, 2026, at 22:36, Patrick James via gnucash-user > <[email protected]> wrote: > > While I suspect that it's possible to stitch XML files together, this is not > something I recommend. > > What I do recommend is exporting the transactions using the CSV export tool > from one and import into the permanent book. > > >> On 08/31/2026 8:41 PM PDT Raymond Maass <[email protected]> >> wrote: >> >> >> Hi, all. >> >> Loving Gnucash -- thanks so much for all the development and maintenance to >> help make it what it is. >> >> TL;DR -- Are GUID's for elements (e.g. transactions/splits) in the >> xml-formatted save files generated and used such that they are required to >> be anything other than simple unique identifiers? I'm not sure if this >> makes sense, but I'm worried that, in addition to being unique identifiers, >> they may also serve as some sort of check-sum for consistency like I >> believe git commits do. >> >> A few more details: >> I'd like to be able to have my wife and me both able to interact with our >> joint gnucash file via a hosted git repository as a way to >> (a) track history with a bit more detail than the auto-generated backup >> files >> (b) allow us to both work on the same file >> >> So far, I set gnucash on our two separate computers to each save as xml >> without compression, making the git diffs quite readable and enabling merge >> conflict resolution to merge changes back into the main branch when >> conflicts arise. >> >> When we have both done some basic work (e.g. entering some transactions), >> and then want to merge our files, it is generally a relatively >> straightforward process of making sure all the transactions in the xml file >> are present in the resulting file. We could also update the transaction >> count that is stored in the file, but I've found so far that leaving that >> not updated doesn't seem to cause problems (making me wonder what it is >> there for). >> >> I've done a few basic tests where I take a simple file and carry out that >> workflow, then reopen the merged file in Gnucash. So far, the result always >> seems to be as expected with all separately entered transactions present. >> >> So my question is whether anyone sees any potential issues with this. One >> particular worry that came to mind is about the GUID's in the file. Each >> transaction and sub-component like the split lines has a GUID. When I merge >> the files, I simply copy the corresponding lines for each transaction into >> the merged file with whatever GUID was made on the branch. >> >> Are the GUIDs generated and subsequently used in any way that might cause >> consistency problems later such as a checksum of the save file at the state >> they were added? Or am I okay as long as they're all unique, even if they >> were generated and manually merged from, effectively, two different gnucash >> files (from branches)? >> >> Bonus question: >> Is there a particular algorithm for generating valid GUID's, or can they be >> any (unique) valid string with the allowed characters? I'm somewhat >> interested in the idea of programmatically adding elements to the xml file, >> and this would be a consideration in doing so. >> >> Thanks, >> Ray >> _______________________________________________ > _______________________________________________ > gnucash-user mailing list > [email protected] > To update your subscription preferences or to unsubscribe: > https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.gnucash.org%2Fmailman%2Flistinfo%2Fgnucash-user&data=05%7C02%7C%7C979988d0ae984a77ec0408df084e401f%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C639238804311305733%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=lYpI51fru7nRMzxgGxZWzwNh0M59DhEew8HO4F5j2KI%3D&reserved=0<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://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.gnucash.org%2Fmailman%2Flistinfo%2Fgnucash-user&data=05%7C02%7C%7C979988d0ae984a77ec0408df084e401f%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C639238804311338372%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=CgYuqdzc%2B7qoBanwxG0xgW838GGoXRwEA6fdD3G8Wsg%3D&reserved=0<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.
