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

[Michael or Penny Novack]

> Yes, except that it does make for rather long filenames.  I'd really
> be happiest if my GnuCash 'building' bank account data file was simply
> called 'building'.  It's in a directory called ~/pcc/2022 which tells
> me that it's Parochial Parish Council data for 2022.
>
It is probably because of my decades in the cypher mines (and working 
under mainframe OSs) that I am seeing "file name" differently that you.

I see ALL file names as "long" because the FULL NAME of files IS long. 
Most modern OSs allow you a "shortcut" in specifying file names by 
allowing you to specify being in a directory (aka file folder) and then 
you specify the "name" as from that point outward. In other words, you 
don't have to include in the file name you specify the path of that 
directory. Everything in that directory has THAT part of the (full) name 
in common.

It's also why I see being able to HAVE long file names (the part we 
usually see) as good/freedom since back in those days not allowed to be 
more than 8 characters.in any part of the name. It In other words, why I 
consider being able to have long file names a benefit, not a curse.

Dates as part of the names? Well once upon a time one at of the largest 
"financials" in the world somebody goofed and a previous week's backup 
of a file was reloaded (they used cycle names, A, B, C, etc. so all 
files for the A run had an .A. in a name (in the file system of this OS 
"." not "/" to separate parts of path). So all the jobs in the A run, 
the B run, the C run, etc had the file names correct for that run. BUT 
-- the names repeated in a cycle so a mistake of the sort I described 
was possible.      This happened on a Thursday, discovered the next 
Monday, and it took till Friday working around the clock till we were 
caught up (rerun Thursday, rerun Friday, then do Monday => )   They 
asked me, "Mike, can you come up with something so that this can never 
happen again?"

My solution was instead of cycles that repeated, a DATE associated with 
the run. Of course beyond human effort to edit all the names in each job 
of the run for that, so one directory with the jobs having symbolics in 
the names (for things like "this run", "previous run", "last months 
run", etc) and a program that given this directory and a "date of run" 
would edit all of those jobs into another directory with all the 
substitutions made and then these would be the jobs for that run, names 
never used again >> I was an "applications" programmer but for this tech 
support declared me "honorary tech support" and gave me my own set of 
system manuals just for the presentation of the concept (I was of course 
also the person who then designed and wrote the actual calendar and 
editor programs)

So yes, I look at dates in file names as a very good thing. If like me 
you had lived through that "hell week" trying to get caught back up you 
would too.

With gnucash, I am not closing the books but I DO make backups, and the 
year end one is special. A copy goes offsite and for organizations, an 
additional  copy to another officer to be usable as proof (by compare) 
that I didn't alter books. So all of the books do have the current year 
in the name of those copies, and then the active file gets renamed for 
the next (now current) year.

Ask yourself -- if I am using "what directory it is in" to indicate 
correct file (correct year), what could go wrong?

Michael D Novack