GnuCash could not obtain the lock file...

Xavier Lagraula detunizedgravity at gmail.com
Thu Feb 12 09:58:34 EST 2015


Hello all,

I would like to add a little word of caution here, for those who are
tempted to answer "OK, you can ignore the existing lock file" to gnucash or
to other applications when facing the same circumstances.

Usually, when you are shown this kind of pop up it means that something
went wrong. In your case you knew what caused the problem, and you knew
that the reboot was safe (as in: all files were properly closed and left in
a coherent state). But in the usual case it is far from certain. There
might have been a power outage, for example, or a blue screen, or whatever.
In such a case you cannot know for sure that the data files that were open
when the incident occurs are in good shape. If it happened precisely when
some modification was written to the disk, then all bets are off.

In the worst case, reopening them without caution may very well mean losing
any hope of salvaging their content.

So my take on this kind of situation is:
* Quit.
* Copy your (potentially corrupt) data files somewhere else.
* Relaunch the app and bypass the warning
* Check that everything is alright. Twice.
* Only delete your temporary backup after a while, when you are completely
sure that your data is safe.

BR,
  Xavier



Le Thu Feb 12 2015 at 14:23:18, Mike or Penny Novack <
stepbystepfarm at mtdata.com> a écrit :

>
> > Yep, that's what I did and it looks like it works OK.  Thanks for the
> info
> > on the lock file.
> >
> > Kind regards,
> >
> > Greg Feneis
> But for your original question "what is it?" maybe worth an answer
> because the mechanism is a very common one (not just gnucash) and
> sometimes either the "override" option doesn't work or the application
> doesn't give you one.
>
> Under almost all operating systems, a program can test for the existence
> of a file even if it doesn't have permissions to open that file and the
> testing won't disturb another program that might be using the file at
> the time. So a simple method of making sure that only one application
> can be using a file is (after testing that no lock present) is for an
> application to create a (temporary) file with the same name but
> extension .lck. This file isn't USED, just has its existence tested for.
> When the application that is using the file closes it, it deletes that
> lock file, so now another application can use the file. If an
> application tries to use the file in the meantime, it sees that lock
> file and  reports, "can't get the file, it is locked."
>
> But if there is a crash or other abnormal termination, the lock file
> didn't get deleted, so any application trying to use that file reports
> "locked".
>
> If you get that message, up to you to decide what the situation is. Up
> to you to make sure that there ISN'T something running that is using the
> file (a legitimate "in use"). But if you decide OK, then you override
> (if that is an option) or if no override provided or if it doesn't work,
> you go into the directory (file folder) where the file you want lives,
> find the lock file, and manually delete it.
>
> Michael D Novack
> _______________________________________________
> gnucash-user mailing list
> gnucash-user at gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-user
> -----
> Please remember to CC this list on all your replies.
> You can do this by using Reply-To-List or Reply-All.
>


More information about the gnucash-user mailing list