Glen Ditchfield writes:
> On Mon, 26 Jun 2000, Dave Peticolas wrote:
> > This is the second version of the backup proposal.
> > ...
> > When GnuCash starts, it should check for the presence of the log file
> > and, if it exists and has a later modification time than the main
> > file, GnuCash should prompt the user to load the log file in addition
>
> I don't want to trust file modification times; sometimes they get changed. H
> about logging 'save' events, with matching timestamps or some such in the
> saved database and the log entry? When GnuCash starts, it checks the log. I
> the last entry isn't the 'save' for the database, something went wrong.
What if we just used the existence of the file? If the save was successful,
the log file should have been moved to the historical log file anyway.
> > + GnuCash should maintain log histories, rather than save histories, to
> > handle failure #3.
> >
> > After saving, the current log file should be renamed to be the first
> > log history file, and a new log file should be started.
>
> Wouldn't it be simpler to have just one log file, and keep appending to it?
> Fewer file operations means fewer opportunities for disaster. Logging, log
> loading, undo, and miscellaneous scheme utilities would be less complicated
> because they won't have to handle multiple log files, some of which could be
> missing. (But you would need to give users a way to chop the front off of th
> log when they want their disk space back.)
I'm not sure recovery would be simpler, since if you are recovering from
the backup database and the log, you would need to know what position in
the log to load from. Since the log may have been 'trimmed' in the interim,
this would be problematic.
dave
--
Gnucash Developer's List
To unsubscribe send empty email to: [EMAIL PROTECTED]
