Transaction Log after crash

Derek Atkins warlord at MIT.EDU
Fri Feb 13 09:13:59 CST 2004


Hi,

Thanks for offering to help with gnucash.  I'd suggest that you
subscribe to gnucash-devel and we should move this discussion over
there.  Please remove gnucash-user from the CC but leave gnucash-devel
in the CC when you reply.

Benjamin <benjamincarlyle at optusnet.com.au> writes:

[way to kill gnucash elided]

> 1) Start gnucash again.
> Gnucash says that it can't get a lock for my file. It wants to know whether to 
> quit, open anyway, or create a copy. I don't want it to do any of those 
> things, so I go to 2)
> 2) Manually delete myfile.LCK
> 3) Close and restart gnucash.
> Gnucash comes up ok, now, but is missing my unsaved transactions

FTR, what you did in #2 and #3 is exactly what "open anyway" does.

> 4) File -> Import -> Replay gnucash .log file
> The open dialogue places me in my home area, instead of where my accounts file 
> is. I navigate to the accounts file location. I see the following files:

Yea, I agree that it should start in the directory of your data file.
I don't know why it doesn't.

> 5) Choose myfile.20040213002043.log
> At this point I see nothing happen at all! :)
> The account totals don't update. I only realise that the log has been applied 
> when I open the account I expected to change and find the new transactions 
> already there. I don't know of any way to update the account totals, apart 
>>From closing and reopening the file (hoping this isn't a sign of 
> corruption ;)

Yea, this is definitely a bug, too.  It looks like some update events
are not being sent properly.

> So.
>
> The two main problems I see in this are the LCK file management and the 
> selection of the log... I'll treat the account balances not updating as an 
> out-and-out bug for the purposes of this email :) The LCK file's existence 
> doesn't imply a living gnucash process, and the name of the log file is 
> obscure, especially among a large set of similarly-named files. Is the reason 
> an OS lock isn't used for the LCK something to do with antiquated NFS 
> implementations that don't support locking? Is there some assistance you 
> could give the user in both finding that they need to import the log and 
> finding the file?

Your help would be greatly appreciated..

First, I don't see the LCK file management itself as a problem.  It's
doing the right thing with the file; it's the UI surrounding the
existence of the lock file that's a problem.  Besides, it's not just
NFS that has problems locking (and the lock problems are not
antiquated -- NFS _still_ has problems locking).  The LCK file is also
used to detect crashes in the program to warn the user that there is
something potentially wrong.

This is key!  When you start gnucash and it finds a lock file, there
is NO WAY to determine whether the LCK file exists because:

 a) someone else is currently using the data file, or
 b) gnucash crashed.

> Anyway, here is my proposal:
> * Write the name of the log file into the LCK file, or use the LCK as your log 
> file

I see no reason to do this.  Why do you feel this would help?

> * Lock the LCK file with a real OS lock so that you can ask the OS if the file 
> is still locked. An OS lock will go away if your process crashes, but a file 
> will not.

This is not sufficient and not portable.  It also doesn't work on many
networked file systems.

> * On startup, check the existence and lock of the LCK file. If one exists and 
> is unlocked, lock it and ask the user if they want to reapply the 
> transactions from the data the LCK file refers to.

While reasonable in theory, again it's based on flawed assumptions that
file locking actually works in a networked file system environment.

> I suggest text like "The previous session of gnucash appears to have 
> terminated prematurely. Some transactions you entered after your last save 
> are still available, saved separately to the main file. Restoring the 
> transactions will not affect your main file until your next save, and if you 
> decide you don't want them you can exit without saving. Do you want to 
> restore them?" or maybe something as simple as "Restore unsaved transactions 
>>From previous session? You should usually answer 'yes'.". You could supliment 
> the short form with an "Tell me more..." button with more complete 
> explaintory text. You'd still want to allow the option to say 'no', primarily 
> for the case where restoring the transactions is what causes the crash :)

A reasonable suggestion if there were a sure-fire, portable way to
actually lock the data file.

> At the very least, if everything else stays the same, I'd like to see the 
> "I've just found a LCK file with no lock on it" event cause gnucash to guide 
> the user step-by-step through the recovery process.

Agreed, this should happen.

> I can live with crashes. Every application has them I've certainly seen them 
> with quicken and gnucash alike. I can live with having to press the save 
> button to create a fresh XML file every time I exit the application. I can 
> live with slow startup times (quicken under wine takes longer!). I just need 
> to know that I'm going to be able to get at my unsaved (but logged) data when 
> gnucash does crash, and I need to be able to explain the procedure to my wife 
> over the phone when she calls me up saying "gnucash crashed and I had just 
> entered all my receipts!" "No! I hadn't saved, yet. I was just looking 
> through the graphs first."
>
> So, is anyone looking at this? Would it be worth me looking at this? I'm a 
> programmer, but haven't ever used gtk nor programmed in scheme. Have I missed 
> something vital? Thoughts, anyone?

Why do you think you'd need to know scheme to do this work?  You don't
need to know scheme for this; it's all C.  The only vital issue you've
missed is the lack of a working, portable lock mechanism.

You're welcome to add the code to do this, but honestly the XML file
storage backend has been deprecated, so I'd much rather see work done
towards real features.  The plan is to move to an embedded SQL storage
like SQLite for the main storage, and relegate the XML format to where
it belongs: an interchange format for exporting and importing data.

Having said that, any patches you send that actually fix bugs or improve
the program are welcome!

> Benjamin.

-derek

-- 
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       warlord at MIT.EDU                        PGP key available


More information about the gnucash-devel mailing list