[GNC] Risks of merging xml save files

Tue Sep 1 23:59:32 EDT 2026

Hi, all.

Thanks, everyone, for the comments, information, guidance, suggestions.

Jim, the comments about GUID's, how they are (not) used, and how they're
generated are great.
Patrick, the csv import/export idea is definitely a nice alternative to
consider.
John, I also hadn't thought much about using the GnuCash API. Probably also
worth considering more.
Kalpesh, it's a good reminder to be aware of security concerns with hosting
this sort of information. Although I didn't quite follow the comments about
the xml file not being plain text. Opening one (not compressed) in a text
editor reveals structured and relatively easily readable/understandable
text.
Matthew, interesting ideas about how to potentially manage with a syncing
service. I've also encountered some challenges with this approach as John
also highlighted would happen, and we navigated them with various
communication strategies that sound less effective than what you've cooked
up.

Jim and John, the various comments about challenges with the merge are well
taken. John, you are certainly right about the example you gave: git's
default merge guess was doing absolutely the wrong thing with it, trying to
keep only one copy of similar lines in the transactions. I think the saving
grace here is that (with the simple trial examples I've played with so far,
at least), git was at least smart enough to realize there were merge
conflicts and ask for my intervention. In that case, it has been rather
straightforward to read over the conflicting xml files and make sure that
the resulting file has complete transaction entries rather than the
treat-it-like-code interpretation of how git is suggesting they should
maybe be merged. If we were to encounter an example where the merge didn't
raise conflicts for us to review and fix, we'd almost certainly end up in
trouble. Hopefully we would end up with a file that fails to open, causing
us to immediately go back and figure out what went wrong.

Overall, understood a broad recommendation against the idea. It also seems
like, with very careful attention to and manual intervention in the merging
process to make sure the results follow the understandable and consistent
xml structure, it . . . might work.

We'll think through if the highlighted risks and potential pitfalls are
worth the potential upsides of having an ability to occasionally work in
parallel. Or maybe one of the proposed alternatives may work.

Thanks again!
Ray

On Tue, Sep 1, 2026 at 6:20 PM Matthew Newman <mnewman135 at outlook.com>
wrote:

> 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 <gnucash-user-bounces+mnewman135=
> outlook.com at gnucash.org> on behalf of John Ralls <jralls at ceridwen.us>
> Sent: Tuesday, September 1, 2026 1:25 PM
> To: Patrick James <patrickjames14 at comcast.net>
> Cc: gnucash-user at lists.gnucash.org <gnucash-user at lists.gnucash.org>
> 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 <
> gnucash-user at gnucash.org> 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 <raymondbarrettsmith at gmail.com>
> 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
> > gnucash-user at gnucash.org
> > 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
> gnucash-user at gnucash.org
> 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
> 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.
>