On Monday, December 31, 2018 8:40:40 PM CET Adrien Monteleone wrote: > It should probably be filed in Bugzilla, but I think it might already be > there. >
No for enhancement requests uservoice is fine. We haven't stated this explicitly I think, but I find it easier if bugzilla is really for tracking bugs. > I seem to recall asking this question myself some months ago after a thread > about user confusion over these files. I unfortunately can’t find the > thread and don’t remember the exact final point, but I do remember one of > the devs stated a good reason for why the present situation is what it is, > darned if I can remember it though. Maybe one of them will chime in. > I don't remember exactly either. I believe at the last discussion we were debating removing the logging functionality for sql backends and I almost did. There are several issues with the transaction log and it only provides a false sense of security. For example it only logs transaction changes, not account changes or any other modification made to the data. So as a recovery tool it's only marginally useful. Worse, it will restore bad transactions if business features are used. And probably there are several other issues with it. Given these issues I think I should have proceeded with removing the logging for the sql backend after all. As a whole I think this logging is in dire need for a redesign. Given the future ideas the dev team has with the xml backend (on load convert it internally into an sqlite db as long as it's open), it's probably best to hold of on that one though. I think a lower level implementation (on the sql transaction level) has a better future. But that's only tangential to the proposal of moving the backup and log files someplace else. That is also not a new idea. I have also suggested this in the past. > >> I understand the usefulness of the log files, but why aren't they written > >> to the temp folder? Or better yet, why aren't they written to a > >> user-specified location, with the temp folder as default?> > > This sounds like an idea that needs to be filed as an enhancement > > request. I'd suggest an alternative might be to create two sub-folders > > in the folder where the data file is stored: > > > > 1. ./GnuCash-Backups > > 2. ./GnuCash-Logs > > Using subdirectories is one strategy, though I would not suggest the split above. I'd go for one subdirectory per data file (people sometimes forget you can have more than one book). If your book is called MyBook.gnucash, the related subdirectory could for example be called MyBook.history. And then we store all related files in there. We could also think a bit broader and extend the usefulness of this directory to also hold other associated files. In that case a name like MyBook.extra could make more sense. In addition as logging also happens for the sql a I also see another approach: gnucash already keeps metadata in GNC_DATA_HOME. We could choose to store logfiles and backups in there as well. They are used relatively infrequently so there's no need to have them clutter the directory of the main data file. Regards, Geert _______________________________________________ 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.