[GNC] Locked out of gnucash

[Stephen M. Butler]

On 11/25/19 11:01 AM, David Carlson wrote:
> If I understand, Derek, you are proposing a change to GnuCash code to
> improve it's behavior.
>
> Going back to the original question, which was about the confusing wording
> of the warning, if the code is changed, should there be warnings tailored
> to each of the three cases?
>
> Note: Case 1 might mean that some third party app such as a file editor may
> be mucking around.  Is this true?  Is it possible to test the PID to see if
> it is dead or alive?
>
> On Mon, Nov 25, 2019 at 11:47 AM Derek Atkins <derek at ihtfp.com> wrote:
>
>> Adrien Monteleone <adrien.monteleone at lusfiber.net> writes:
>>
>>>> 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.
>> Using a "machine-name + PID" will absolutely work, because:
>> 1) If the machine-name is the local machine, you can check the PID and
>>    if the PID is not gnucash, you know it was an unclean exist.
>>
>> 2) If the machine-name is the local machine, you can check the PID and
>>    if the PID IS gnucash, you know there is another running instance.
>>
>> 3) If the machine-name is NOT the local machine, then you cannot
>>    differentiate what's going on and should ask.  Most likely it IS open,
>>    but there's no good way to tell.
>>
>> The good news is that #1 and #2 ARE the most common use-cases today, so
>> we should implement that.
>>
>>> Regards,
>>> Adrien


You have one more case to consider for the local machine -- PID does not
exist (might be considered a special case of #1).

As for being dead/alive, on Linux as long as the PID exists, you need to
consider it might do something (unless it is marked to be killed).

Oh, for #2, it might be that the new process gets the old PID back
(weird but doable).  So you might want to check if the PID is yours! 
That would imply a crash of the prior process.  (or on a Quantum machine
that you have entered duality).

-- 
Stephen M Butler, PMP, PSM
Stephen.M.Butler51 at gmail.com
kg7je at arrl.net
253-350-0166
-------------------------------------------
GnuPG Fingerprint:  8A25 9726 D439 758D D846 E5D4 282A 5477 0385 81D8