Bug#291632: Destroys backup files by default with little sanity checking

[Daniel Burrows]

Package: gnucash
Version: 1.8.9-4
Severity: grave

  I'm sitting here watching a (likely futile) attempt to restore two months' 
worth of lost information for a user.  While it's likely that nothing can get 
the data back, I finally think I figured out what happened and how the data 
was lost.  I think the sequence of events is quite likely to occur in the 
hands of a user.  (in fact, I myself would probably only have avoided it by 
accident)

  Here's the deal: when you save a gnucash file, it creates a backup file 
that's indexed by the date on which it was saved.  This backup is very useful 
in the event that you have a program crash or make a serious blunder with the 
interface.  In early November, the user in question did just this: she loaded 
a backup of her Accounts file due to some sort of problem with the program.  
However, this resulted in the *backup* file being used as the new default 
save file and as gnucash's default file to load on startup.  Accounts 
remained frozen in a state from about November 3.

  All was well until she asked me for help with importing some old Quicken 
data, earlier today.  After importing the data into a separate file, I (not 
knowing that she was using the backup file) innocently opened the file 
Accounts.  Apparently, either this or saving the file Accounts (not sure 
which) triggered GNUCash's helpful backup-purger, which immediately wiped 
out both her main accounts file and all of her recent backups.  We were left 
only with Accounts (the November 3rd edition, remember); two months' worth of 
data entry went down the drain without my knowing.

  Now, I understand why this functionality might be useful, but it seems far 
too easy to destroy data with it at the moment.  I suggest that, at the very 
least, several more sanity checks be incorporated.  For instance, only delete 
a file if:

  (A) there are at least X newer backups *by mtime* of the main file, AND
  (B) the file in question is at least Y days old *by mtime*, AND
  (C) the current sanity checks (that it looks like a GNUcash backup file with 
timestamp Y days ago) apply, where the timestamp takes the LAST date in the 
filename when multiple dates are available.

  (A) makes sure that some backups are always available if you screw up; (B) 
makes sure that GNUcash isn't mislead by confusing filenames (such as 
Accounts.200411060911.xac.200501201015.xac).  At the very least, the 
modification of (C) should be made so that the ill effects of filenames like 
the one above are limited.

  Without some tightening of the criteria, I think the backup-purging should 
be disabled by default, as it's way too easy to unexpectedly lose data right 
now.

  Daniel

-- System Information:
Debian Release: 3.1
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: i386 (i686)
Kernel: Linux 2.6.9-2-686
Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1) (ignored: LC_ALL set 
to en_US)

Versions of packages gnucash depends on:
ii  bonobo   1.0.22-2.2  The GNOME Bonobo System.
ii  gdk-imlib1   1.9.14-16.2 imaging library for use with gtk 
(
ii  gnucash-common   1.8.9-4 A personal finance tracking 
progra
ii  guile-1.6-libs   1.6.7-1 Main Guile libraries
ii  guile-1.6-slib   1.6.7-1 Guile SLIB support
ii  libart2  1.4.2-19The GNOME canvas widget - runtime 
ii  libaudiofile00.2.6-5 Open-source version of SGI's 
audio
ii  libbonobo2   1.0.22-2.2  The GNOME Bonobo library.
ii  libc62.3.2.ds1-20GNU C Library: Shared libraries 
an
ii  libdate-manip-perl   5.42a-2 a perl library for manipulating 
da
ii  libdb3   3.2.9-20Berkeley v3 Database Libraries 
[ru
ii  libesd0  0.2.35-2Enlightened Sound Daemon - Shared 
ii  libfinance-quote-perl1.08-1  Perl module for retrieving stock 
q
ii  libfreetype6 2.1.7-2.3   FreeType 2 font engine, shared 
lib
ii  libgal23 0.24-1.4G App Libs (run time library)
ii  libgdk-pixbuf-gnome2 0.22.0-7The GNOME1 Canvas pixbuf library
ii  libgdk-pixbuf2   0.22.0-7The GdkPixBuf image library, gtk+ 
ii  libghttp11.0.9-15original GNOME HTTP client 
library
ii  libglade-gnome0  1:0.17-3Library to load .glade files at 
ru
ii  libglade01:0.17-3Library to load .glade files at 
ru
ii  libglib1.2   1.2.10-9The GLib library of C routines
ii  libgnome32   1.4.2-19The GNOME libraries
ii  libgnomeprint15  0.37-5  The GNOME Print architecture - 
run
ii  libgnomesupport0 1.4.2-19The GNOME libraries (Support 
libra
ii  libgnomeui32 1.4.2-19The GNOME libraries (User 
Interfac
ii  libgtk1.21.2.10-17   The GIMP 

Bug#291632: Destroys backup files by default with little sanity checking

[Thomas Bushnell BSG]

So it sounds like you did:

Create file named foo.xac
Do lots of edits on foo.xac [set 1]
Then open file named foo.2004xx.xac (a backup of foo).
Do lots of edits on foo.2004xx.xac [set 2]
Then open foo.xac again.
Do lots of edits on foo.xac [set 3], which triggers the backup purger and
  deletes foo.2004xx.xac, and all of the set 2 edits are now gone.

Except, set 2 of the edits created backup files themselves, which
should be named, say foo.2004xx.2005xx.xac.  So even when
foo.2004xx.xac gets deleted by the backup purger on foo.xac, you
should have lots of backups named foo.2004xx.2005xx.xac.

But from my read of the functions in question, there is a bug here,
and the 2004xx.2005xx.xac backups will get deleted
erroneously.

I will make a fix and submit it upstream.

As for the idea that the way backups are done should be improved,
that's certainly true, but the solution (which is in the works
upstream) is actually to replace the whole backend with a database
system that will avoid these kinds of problems entirely.  

If you set the file retention days in preferences to 0, that has the
effect of turning of the backup-pruning function entirely.

Thomas


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]