I think PART of this problem is confusion about "another user". Remember
that need not be another human being. YOU perhaps have more than one log
in << say one with administrator rights and then a another for regular
use >>
Rather than "in use" the terminology MIGHT be "checked out but not yet
checked back in".It might be more obvious to people that the situation
might be "another user has it" OR "crash or other abnormal termination
before was checked back in"
The "lock file" solution is common/standard to allow multiple SEQUENTIAL
users (one at a time). Insufficient to control multiple CONCURRENT users
(more than one at a time-- of course only one of those can WRITE at a
time). If the SQL database were real SQL there would be a "database
manager" to handle that << I came from the mainframe world where that
was DB2 >>
Michael D Novack
On 11/18/2019 11:51 AM, Adrien Monteleone wrote:
On Nov 18, 2019 w47d322, at 9:17 AM, D via gnucash-user
<gnucash-user@gnucash.org> wrote:
On November 18, 2019, at 8:02 PM, Derek Atkins <de...@ihtfp.com> wrote:
Hi,
I think I have a suggestion for some better wording. See below.
How about:
The data file is currently in use. Most likely this means that the data
file was not cleanly closed (due to a crash) after it was last opened.
If you are sure that it is not currently in use by you or another user,
click "Open Anyway". Otherwise, click one of the other options.
The problem with this wording is that the first sentence is directly
contradicted by the second.
It would actually be more accurate to say:
There is a lock file in the system for the requested data file, which means
either that you are running another instance of Gnucash with this file, or that
the file was not properly closed previously (for example, due to a crash).
If you are sure that it is not currently in use by you or another user, click "Open
Anyway". Otherwise, cancel or open the file in read only mode.
[I am working from memory here. I don't recall the exact options. However, I really
dislike the "click one of the other options" wording. Far better to list them
IMHO]
But once we're this far into the weeds, I think you're going to lose most users
anyways.
Note to devs: does it make sense to put the gnucash PID into the lock
file and then check to see if that PID is currently running? That could
help detect whether there is a current process or a crash/unclean
shutdown?
Again, if user A has a data file open, user B shouldn't also open the file. I
don't see how a check for Gnucash instances could work to prevent precisely
this problem, since my machine won't have any Gnucash instances running--but
the file IS being used.
I agree, using the PID won’t work, because although GnuCash is not (yet) a
multi-user app, some people do use it from various machines with the file
stored on a network. A PID check won’t mean anything to one machine when that
PID belongs to a different machine.
Regards,
Adrien
_______________________________________________
gnucash-user mailing list
gnucash-user@gnucash.org
To update your subscription preferences or to unsubscribe:
https://lists.gnucash.org/mailman/listinfo/gnucash-user
If you are using Nabble or Gmane, please see
https://wiki.gnucash.org/wiki/Mailing_Lists for more information.
-----
Please remember to CC this list on all your replies.
You can do this by using Reply-To-List or Reply-All.
--
There is no possibility of social justice on a dead planet except the equality
of the grave.
_______________________________________________
gnucash-user mailing list
gnucash-user@gnucash.org
To update your subscription preferences or to unsubscribe:
https://lists.gnucash.org/mailman/listinfo/gnucash-user
If you are using Nabble or Gmane, please see
https://wiki.gnucash.org/wiki/Mailing_Lists for more information.
-----
Please remember to CC this list on all your replies.
You can do this by using Reply-To-List or Reply-All.