[GNC] Is there a way to handle same-named GnuCash files sensibly?

[Geert Janssens]

Chris,

I have decided to simply do the test.

As an intro, the files in ~/.local/share/books are called metadata files. They store (among 
others) which windows and tabs you had open the last time you used a file, column widths in 
various tabs, filters in registers and so on. They don't contain your accounting data itself.

When you create a new gnucash data file, this file will get a unique ID (the book ID). That id is 
what is used to map a metadata file to a gnucash file. So far so good. Each time you create a 
new file, it will have its own unique book ID and hence it will be mapped to its own metadata 
file, regardless of whether the gnucash data file has a unique name or not.

However, when you copy a gnucash file in your file manager from one directory to another, 
this is not the case. So if you create your 2022 gnucash file by copying the 2021 gnucash file 
to a new directory but with the same file name, both will be mapped to the same metadata 
file. Depending on the use case this is a feature or a flaw. In your case it would be a flaw. 
There is however not much gnucash can do about it, other than rewriting the code to no 
longer depend on metadata files. I once made a proposal in that direction. Unfortunately I 
lack the time to effectively implement it.

Note that if you copy the file to a different name, that new file will not have any metadata 
associated with it. So the first time you open it, there will be no tabs open other than the 
Accounts tab, customizations to this tab are gone, window size is back to default and so on.

Other than copying a gnucash file around in your file manager, you could also create a copy 
by using gnucash' built-in "Save As..." feature. I tested it and it also doesn't change the 
unique book ID. That means that if you save the file under the same name in a different 
directory it will also share the mapped metadata file. It does however behave differently if 
you save to a new file name. In this case the current state of the new file  (which is the one 
currently open when the save operation completes) will also be saved for the new gnucash 
file and will be separate from the original gnucash file.

So in summary, if you want your per year gnucash files to have unique metadata files, you 
have to create them as truly new files (File->New... in gnucash) or use "Save As..." to save 
them under a different name (in any directory you prefer). I don't know which way you 
typically start your new year's books, at least you now know the limitations of the current 
implementation.

Personally I think the Save As... behaviour is flawed. It should create a new unique book ID. I 
can't imagine a use case where this would fail to work (or there isn't a reasonable alternative 
way to achieve the same thing for that alternative use case). If you feel like it you could file 
an enhancement request for this in our Bugzilla.

Regards,

Geert

Op donderdag 5 mei 2022 10:09:17 CEST schreef Chris Green:
> On Wed, May 04, 2022 at 07:18:32PM -0400, Michael or Penny Novack wrote:
> > > Yes, I noticed too that there a files with a number added to the base
> > > name, e.g.:-
> > > 
> > >      building.gnucash.gcm
> > >      building.gnucash_2.gcm
> > > 
> > > ... but I'm not sure that it's a perfect system.
> > > 
> > > I have reverted to having the year as part of the file name and a
> > > wrapper script that finds the data file corresponding to the year
> > > directory I'm in.
> > 
> > UH ... just because you as a human consider abcd and abcd_3 to be the same
> > name misses the point that they ARE different file names as far as the
> > computer is concerned, as different as you consider Fred and Freda
> > different names
> 
> Yes, I do realise that, I was just pointing out what GnuCash appears
> to do if you have two different data files (in different directories)
> with the same name.  I've never had a data file called
> building.gnucash_2.gnucash so (I assume) GnuCash has created that file
> when it found there was already a building.gnucash.gcm file for
> *another* data file.