[GNC] Gnucash logs

Geert Janssens geert.gnucash at kobaltwit.be
Wed Apr 29 05:57:20 EDT 2020


Hi,

For the file based books (xml and sqlite) there are several approaches:

1. Have a book.gnucash and a book.dir side by side, per book you create.
book.gnucash is your actual data file.
book.dir is a directory containing extra files related to this data file. These include log files, 
backup files and can potentially be extended to hold attachments and possibly book metadata
Advantages:
- all data related to one book is stored together in one place. No intermingling of (meta)data 
with other books. Makes it easy to move a book to somewhere else
- as the main book is outside of the the directory it's easy to spot your book to open it.
Disadvantage: per book you will have two items: a file and a directory. At the file management 
level you always have to treat them as one (move them together, back them up together,...)

2. Have a directory book.gnucash and store all data in there in a structured form (logs in their 
own subdirectory,...). To save a book, you enter the book's name and gnucash will create that 
directory for you. Inside the directory your book will now have a generic name (as the directory 
already indicates the unique name) as would log files and backup files. To open a book, you 
select the directory in gnucash and it will open the actual book inside of it for you. Backup 
management could be integrated in gnucash.
Advantages:
- like option 1, all data related to a single book is encapsulated closely together.
- only one single element on the file system level to remember: the book.dir is your book. Makes 
it slightly easier to move things around, make backups and so on.
Disadvantage: double-clicking a file to open it in gnucash will no longer work. The file manager 
will just open the directory for you and the data in there is now private to gnucash. You could 
argue that you can make a double-click on the book file inside the directory would then open 
gnucash for you. It could at the expense of vastly more complicated load code. It now has to 
check for both a file or directory being opened and do the right thing in both cases.

3 Same as 2, except this time the directory will be zipped.
Advantages:
- like option 1, all data related to a single book is encapsulated closely together.
- only one single element on the file system level to remember: the book.dir is your book. Makes 
it slightly easier to move things around, make backups and so on.
- double-click would work again
Disadvantages:
- The single file could become rather huge. Particularly if you also choose to include the 
attachments in there
- Manual backup and log management becomes harder (one has to know how to unzip the 
gnucash file, akin to how libreoffice documents are zipped up directories)
- Embedding backups directly in the data file feels wrong.

4. The approach where one single global log directory is created (like in GNC_DATA_DIR) and 
one single global backup directory. All log and backup files will be written to these global 
directories.
Advantages:
- the directory containing your book(s) will be fully uncluttered. It will effectively only contain 
your book(s). No more backups or logs. So easy on the eye and easy to understand. As you 
don't need backups often, you can find them when needed.
Disadvantages:
- your book and its backups get separated. So if you need to manage your backups you have to 
search for them in another directory
- if you have multiple books the logs/backups of all books get lumped together. For backup or 
cleanup purposes this is more messy. You have to take care to only select the backups/logs for 
the books you are interested in.
- a real risk of file name clashes. If you have two same-named books in separate directories, 
their logs and backups will overlap or even conflict. There are technical solutions for this (we 
use one for the metadata files) but it's cludgy.

5. Just drop the whole multiple backup/log files idea and move to a model similar to libreoffice. 
That is, while a document is open, it keeps one copy of your current state somewhere written to 
disk. In case the program crashes it will offer to restore to the last known good state. Other than 
that rely on the user to have a decent backup solution to revert back to in case of disk failure.
Advantages: 
- clean directory, will only hold your actual data files
- guard against data loss in case of a program crash
Disadvantages:
- won't allow to go back to older known save states. Users will have to implement their own 
backup strategy for that.

Personally I don't think 2, 3 and 4 are good candidates. They all have significant drawbacks that 
will confuse new and less experienced users. 5 is controversial. I have added it anyway to test 
common opinion on that idea. 1 is the most conservative in terms of number of changes to 
make and in my personal opinion a good trade-off between value and complexity.

Note none of this even considers mysql of postgresql based books. Granted they don't have the 
same clutter problems wrt to backups. But they do also write log files (for those who don't know, 
you will find them in GNC_DATA_DIR/translog).

Regards,

Geert

Op woensdag 29 april 2020 08:54:22 CEST schreef Chris Good:
> -----Original Message-----
> From: David T. <sunfish62 at yahoo.com>
> Sent: Wednesday, 29 April 2020 4:11 PM
> To: Chris Good <goodchris96 at gmail.com>; 'David H' <hellvee at gmail.com>
> Cc: 'Gnucash Users' <gnucash-user at gnucash.org>
> Subject: Re: [GNC] Gnucash logs
> 
> If the setting were per book and user-configurable, then a user could choose
> to set each data file to use a different set of folders, by changing the
> file default from "logs" to "logs-file1"
> 
> Does the Attachments functionality provide a blueprint for how this could
> work for backups and logs? It seems to me that there is a setting somewhere
> that allows the user to point to a particular folder for external file
> association (although my attempts at locating that setting have failed).
> 
> But your point about the logs and backups having different filenames is apt
> as well.
> 
> David T.
> 
> On 4/29/2020 8:55 AM, Chris Good wrote:
> > From: David H <hellvee at gmail.com>
> > Sent: Wednesday, 29 April 2020 12:49 PM
> > To: Chris Good <goodchris96 at gmail.com>
> > Cc: Gnucash Users <gnucash-user at gnucash.org>
> > Subject: Re: [GNC] Gnucash logs
> > 
> > 
> > 
> > Chris,
> > 
> > 
> > 
> > How would you see this working with my 2 data files that I have in the
> > same gnucash folder ???  Would the subdirectory(ies) include the name of


More information about the gnucash-user mailing list