GNUcash crashes on save - losing all changes

[Vincent V]

Excuse the dramatic title (although it is true) but someone else had a
similar problem recently so I thought it would attract their attention.

The good news is that the problem is easily reproducible so tracking
down the bug should be possible. I discovered it by accident when moving
my company accounts files from my home PC to my new office PC, I did
this by burning them onto CD and copying them from that. Unfortunately I
did it as root and forgot to select 'Preserve permissions' in K3B so the
copied files were all owned by root but had global read permissions. I
am running Mandrake 9.1, but I don't think this has anything to do with
the bug.

To reproduce the bug:
Make the directory which contains the accounts file and the files within
it read-only
Start GNUcash from the menu and open the file (if it automatically opens
the file at start up the result is the same)

You get the message:
GNUcash could not obtain the lock
Select 'Open Anyway '
Made some changes - actually you don't need to make any changes to get
the bug
Save the file, you get the message:
Error: An error occurred while processing /path/filename
Select OK then Cancel on the File Save dialogue that appears
Save again (originally I did Save As), you get the message:
Application "/usr/bin/guile-1.41" (process 16239) has crashed due to
a fatal error. (Segmentation fault)
Select Close

And that's it, GNUcash terminates without saving your changes


Vince

[John Zoetebier]

Post by Vincent V
Excuse the dramatic title (although it is true) but someone else had a
similar problem recently so I thought it would attract their attention.
The good news is that the problem is easily reproducible so tracking down
the bug should be possible. I discovered it by accident when moving my
company accounts files from my home PC to my new office PC, I did this by
burning them onto CD and copying them from that. Unfortunately I did it
as root and forgot to select 'Preserve permissions' in K3B so the copied
files were all owned by root but had global read permissions. I am
running Mandrake 9.1, but I don't think this has anything to do with the
bug.
Make the directory which contains the accounts file and the files within
it read-only
Start GNUcash from the menu and open the file (if it automatically opens
the file at start up the result is the same)
GNUcash could not obtain the lock
Select 'Open Anyway

This happens if:
- the folder is not writable
- there is already a lock open, because someone else has the lock

This is a message you should take seriously.
Ignoring error messages can have serious consequences.

Post by Vincent V
Made some changes - actually you don't need to make any changes to get
the bug
Error: An error occurred while processing /path/filename
Select OK then Cancel on the File Save dialogue that appears
Application "/usr/bin/guile-1.41" (process 16239) has crashed due to a
fatal error. (Segmentation fault)
Select Close
And that's it, GNUcash terminates without saving your changes

Of course, your changes are not saves due to folder and file permissions.
This has nothing to do with GnuCash issue.
You could argue that GnuCash should check permissions on the folder first.
But in that case I can think of an other dozen things that can be checked
upon startup.
I feel, the first mistake was to ignore a valid error message, that you
should have checked in the first place.
Maybe someone was hacking your system and entering transactions on your new
PC :)

[Graham Leggett]

Post by John Zoetebier
Of course, your changes are not saves due to folder and file permissions.
This has nothing to do with GnuCash issue.

If Gnucash segfaults for any reason, even due to user error, it is a
Gnucash issue.

The correct behaviour should be to tell the user the file could not be
saved at that location, then offer a new location to save to.

Remember that human interfaces to software are like customer services
representatives in a company. The customer may be wrong, but that
doesn't give the representative leave to simply cut the customer's phone
call off.

Post by John Zoetebier
I feel, the first mistake was to ignore a valid error message, that you
should have checked in the first place.

Never assume any reasonable behaviour from the user. If Gnucash allowed
the user past the load-a-locked-file point, it is responsible for
behaving sanely after that.

Remember what you might have thought was a mistake, might not have been,
as the user may have had better knowledge than gnucash of the status of
the lockfile.

Regards,
Graham

[Vincent V]

Thanks for the input John, but Graham has really picked up on the main
point of my message.
The reason I sent it in was because another (new) user had reported
something similar but was unable to replicate it. I, the on the other
hand, suspected what the cause might be and did a bit of experimenting
to prove it. As a software engineer myself, I know that the first thing
you need to do to pinpoint a bug is to reproduce it systematically, so
this information should be useful to the developers.

When the 'file lock' warning (not error) came up I thought it had
something to do with my file transfer and when it refused to save I was
pretty sure that the file permissions were wrong for some reason, but it
should have allowed me to do a 'save as' and under no circumstances
should it have crashed.

By the way, did you try it yourselves and get the same results?

Thanks again

Vince

[John Zoetebier]

Post by Vincent V
Thanks for the input John, but Graham has really picked up on the main
point of my message.
The reason I sent it in was because another (new) user had reported
something similar but was unable to replicate it. I, the on the other
hand, suspected what the cause might be and did a bit of experimenting to
prove it. As a software engineer myself, I know that the first thing you
need to do to pinpoint a bug is to reproduce it systematically, so this
information should be useful to the developers.
When the 'file lock' warning (not error) came up I thought it had
something to do with my file transfer and when it refused to save I was
pretty sure that the file permissions were wrong for some reason, but it
should have allowed me to do a 'save as' and under no circumstances
should it have crashed.
By the way, did you try it yourselves and get the same results?

I repeated the steps and got the same result, if the folder is read-only.
If only the files are read-only there is no problem.

In this case you can argue that the system should check file permissions
before continuing or saving files.
However there are a zillion other ways in which things can go wrong and if
GnuCash wants to check for each of them people will start complaining that
it is so slow.
I still feel that GnuCash gave a valid warning message.
In addition I feel that the design of an application can make some
reasonable assumptions about its environment.
Otherwise you end up replicating a security system in your application.

Someone suggested to display a "save as", however from a security point of
view this may be not acceptable.
For example you have a read-only version on CD ROM which you use for demo
purposes on a trade show.
Now you do not want people to make a copy of your data by using "save as"
,right ?
This may not be the best example, but my fear is that at last people want
the system to make coffee as well :)

[Vincent V]

Guys

My understanding of the 'Open Anyway' option on the file lock warning is
that the programmer was actually trying to be thoughtful, I don't think
this option used to exist.

When GNUcash opens an accounts it writes a couple of temporary files to
indicate that the file is in use, when it closes the accounts file it
deletes them. If it fails to write them it assumes that they already
exist and puts up the 'file lock' message, their existence could mean
that someone else is using the accounts file or might be because GNUcash
did not exit cleanly for some reason and so failed to delete them in a
previous session. Without the 'Open Anyway' option the poor user would
have wade through the FAQs and other documentation to find the brief
passage that tells you that, should you receive this message, you must
navigate to the account files' directory and delete these files by hand.
Having to go through all this palaver is a pain for anyone and beyond
many desktop users. So the 'Open Anyway' saves them the trouble.

Derek is right here, the 'file lock' message is a 'bug' in the sense
that it makes some assumptions that are not always true and so doesn't
work as the programmer probably intended or the average user might
expect. It should distinguish between inablility to write becasue the
file exists or for some other reason (easy to do).

If the files exist then the user should be warned that 'The accounts
file seems to be in use' (rather than the cryptic 'GNUcash could not
obtain the lock' - which is only meaningful to the developers) and given
the choice to 'Open as read-only' or 'If you are sure that no one else
is using it then Open Normally' or 'Close'

If the files do not exist then the user should be warned that "It
appears that the directory is read - only" and given the choice to 'Open
as read-only' or 'Close'. After all, you might want to grant someone
read-only access to a set of accounts files (your accountant, visiting
tax inspector for instance) so that they cannot inadvertently mess them
up, and the simplest way is to make the directory read-only to them
(rather than all the individual files which will be continually changing
as the backups are written and deleted).

By the way Derek, I did as you suggested and filed the crash bug in
bugzilla.

Vince

[Chris Shenton]

Post by Vincent V
My understanding of the 'Open Anyway' option on the file lock warning
is that the programmer was actually trying to be thoughtful, I don't
think this option used to exist.
When GNUcash opens an accounts it writes a couple of temporary files
to indicate that the file is in use, when it closes the accounts file
it deletes them.

I've just seen this: gnucash died; when I started up, it said it
couldn't get the lock on my previous saved data. I presume the dying
gnucash didn't remove its lock.

So how do I know what file to remove to unlock the lock? Or other
procedure necessary to get out of this condition? Or, if I say "Open
Anyway" will it clear the lock for me?

Post by Vincent V
If the files exist then the user should be warned that 'The accounts
file seems to be in use' (rather than the cryptic 'GNUcash could not
obtain the lock' - which is only meaningful to the developers) and
given the choice to 'Open as read-only' or 'If you are sure that no
one else is using it then Open Normally'

I like this last one :-)

[Vincent V]

The files are in the same directory as the accounts file itself (and all
the backups). There are two (that I have seen), one is called
filename.LNK, the other filename.some.number.LNK where filename is the
accounts file. I have just tested what 'Open Anyway' does by creating a
set of dummy accounts and copying these to files to different directory,
then I closed GNUcash and copied them back.

When GNUcash started I got the 'file-lock' message and selected Open
Anyway and made and saved some changes. It did sort the file-locks when
it closed normally and removed them. (actually the
filename.some.number.LNK had a new number and the original
filename.some.number.LNK was not actually removed until I started
GNUcash a second time - but there was no file-lock message the second
time). So the answer to your question is 'yes' "Open Anyway" will it
clear the lock for you.

Vince

Post by Chris Shenton

Post by Vincent V
My understanding of the 'Open Anyway' option on the file lock warning
is that the programmer was actually trying to be thoughtful, I don't
think this option used to exist.
When GNUcash opens an accounts it writes a couple of temporary files
to indicate that the file is in use, when it closes the accounts file
it deletes them.

I've just seen this: gnucash died; when I started up, it said it
couldn't get the lock on my previous saved data. I presume the dying
gnucash didn't remove its lock.
So how do I know what file to remove to unlock the lock? Or other
procedure necessary to get out of this condition? Or, if I say "Open
Anyway" will it clear the lock for me?

Post by Vincent V
If the files exist then the user should be warned that 'The accounts
file seems to be in use' (rather than the cryptic 'GNUcash could not
obtain the lock' - which is only meaningful to the developers) and
given the choice to 'Open as read-only' or 'If you are sure that no
one else is using it then Open Normally'

I like this last one :-)

[James Leone]

Post by Graham Leggett

Post by John Zoetebier
Of course, your changes are not saves due to folder and file
permissions.
This has nothing to do with GnuCash issue.

If Gnucash segfaults for any reason, even due to user error, it is a
Gnucash issue.
The correct behaviour should be to tell the user the file could not be
saved at that location, then offer a new location to save to.
Remember that human interfaces to software are like customer services
representatives in a company. The customer may be wrong, but that
doesn't give the representative leave to simply cut the customer's
phone call off.

Post by John Zoetebier
I feel, the first mistake was to ignore a valid error message, that
you should have checked in the first place.

Never assume any reasonable behaviour from the user. If Gnucash
allowed the user past the load-a-locked-file point, it is responsible
for behaving sanely after that.
Remember what you might have thought was a mistake, might not have
been, as the user may have had better knowledge than gnucash of the
status of the lockfile.
Regards,
Graham

Although to developers this may seem wrong, I do think that this
attitude, this viewpoint will help Linux gain ground on the desktop. I
hope that developers will be able to cast aside the obvious unfairness
to the developer to allow the end user to achieve more.

I do thank the developers very much, and, only wish additional capacity
for longsuffering to allow the maximum amount of people to benefit from
their work.

JL

[Derek Atkins]

Post by James Leone
Although to developers this may seem wrong, I do think that this
attitude, this viewpoint will help Linux gain ground on the desktop. I
hope that developers will be able to cast aside the obvious unfairness
to the developer to allow the end user to achieve more.
I do thank the developers very much, and, only wish additional
capacity for longsuffering to allow the maximum amount of people to
benefit from their work.

For what it's worth, I agree that anything that causes a crash is a
bug that needs to be fixed. Even if the user ignored the warning at
startup, that does not mean it's ok for GnuCash to crash. While I
wish users wouldn't ignore warnings, they do. The program should deal
"properly" when they do (where "properly" means at least "doesn't
crash").

The bottom line: the program should never crash.

Vincent: my suggestion to you is to file a bug report at
bugzilla.gnome.org to make sure this information doesn't get lost.
Thank you for tracking it down to a permission problem -- we should
track THAT down, too, and try to present a better error message. (So
perhaps there are two bugs here -- the crash, and the error message
when it fails to write the file).

Post by James Leone
JL

-derek

[CL Gilbert]

Derek Atkins wrote:
~ >
| For what it's worth, I agree that anything that causes a crash is a
| bug that needs to be fixed. Even if the user ignored the warning at
| startup, that does not mean it's ok for GnuCash to crash. While I
| wish users wouldn't ignore warnings, they do. The program should deal
| "properly" when they do (where "properly" means at least "doesn't
| crash").
|
|
|
|
|
| -derek
|

I thought warnings were ment to be ignored.

Now an actual 'Error', I never ignore that. :)

Of course I am only 1/2 kidding.


- --
Thank you,


CL Gilbert
"Then said I, Wisdom [is] better than strength: nevertheless the poor
man's wisdom [is] despised, and his words are not heard." Ecclesiastes 9:16

GnuPG Key Fingerprint:
82A6 8893 C2A1 F64E A9AD 19AE 55B2 4CD7 80D2 0A2D
GNU Privacy Guard http://www.gnupg.org

Free interface to Freechess.org
http://www.rigidsoftware.com/Chess/chess.html