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
_______________________________________________
gnucash-user mailing list
gnucash-user@gnucash.org
To update your subscription preferences or to unsubscribe:
https://lists.gnucash.org/mailman/listinfo/gnucash-user
If you are using Nabble or Gmane, please see
https://wiki.gnucash.org/wiki/Mailing_Lists for more information.
-----
Please remember to CC this list on all your replies.
You can do this by using Reply-To-List or Reply-All.
