ENB: Proposal re #199: handling already-open files

[Edward K. Ream]

#199 is presently the most serious bug in Leo.  Sometimes, but not always, cancelling the load of an already-opened .leo file will hard crash Leo (Python).

This post is an Engineering Notebook post.  It's most notes to myself and Terry.  Feel free to ignore.

I am studying a core dump on Ubuntu.  It's been fun learning about apport-retrace, but not that much fun.  Terry's analysis of the problem is good enough for me.  It's time to solve the problem with design, not mere code.

The original problem

Leo should indeed warn users when they attempt to open an already-open file, call it f.leo.  Saving either copy of f.leo could destroy data previously saved in the other copy of f.leo.

The problem is not actually very serious, because Leo already warns if f.leo has been changed outside of the presently executing copy of Leo.  For example, suppose two invocations of Leo exists.  Let's call them A and B.  Suppose Leo A saves f.leo. Later, if B saves f.leo, Leo B will issue a warning that f.leo has been changed outside of B.

Still, I think it is best to warn the user if f.leo is already open.

The mechanism for checking for already-open files is fine. Leo makes entries in the global db file when opening a file and deletes entries in the db when closing the file. This can lead to spurious "already open" messages if Leo is killed rather than being closed normally.  The db will contain an entry for a .leo file that is not, in fact, open. Happily, this has never been a big deal. Furthermore, the following scheme handles this case even more smoothly than before.

Proposal: always open files, even if already open

Leo will no longer issue per-file requests for guidance.  Instead, Leo will open all possibly-already-open files, putting warnings about them in the log. Finally, Leo will raise a single warning dialog.  This dialog will list the files that might already be open, and suggest that the user close duplicate files in whatever copy of Leo is more convenient.

This scheme solves several problems:

1. Leo always loads files. This instantly eliminates the possibility of hard crashes.

2. It's faster than the existing scheme.  The user only has to dismiss the summary dialog.

3. The user will never have to choose right now what action to take. Such choices are always odious and stressful.  Instead, the user can choose to close the duplicate f.leo file in either A or B.  In most cases, it's safe to leave both copies open, as long as both don't change.  To repeat, Leo will issue a warning if that happens.

4. Closing a duplicate file, in either A or B, automatically clears the db entry for that file.  There is no need to ask the user whether to reset the db!

The only complication will be knowing exactly when/where to issue the warning dialog.  The details will be different depending on whether Leo is loading multiple files at startup, or loading a single file later.  But this is only a coding detail.

Summary

A single dialog that warns about possibly-already-open files is the simplest thing that could possibly work:

- It's easy to code.
- It will stamp out hard crashes.
- It's simpler, faster, more flexible and less stressful for the user.

Unless there are strong objections to this scheme, I plan to put it into effect immediately.

Your comments, please, Amigos.

Edward

[Terry Brown]

This sounds ok to me - there's something wrong in the current code that
could perhaps be hunted down, but I know I already fixed one
reproducible bug in this area so it's obviously a hairy area. So the
below approach seems like the most robust.

I'd just add that the use case I have mostly is "yes to all". I.e.
they're not really open elsewhere. Hmmm, I guess there's nothing to
add to the below to deal with that - the warnings / dialog should say
"this / these outlines *appear* to be open elsewhere" - in my case it
arises from killing Leo accidentally in virtual machines, VNC
connections, dropped X11 forwarding etc.

Cheers -Terry

On Sat, 20 Jun 2015 16:01:07 -0700 (PDT)
"Edward K. Ream" <edre...@gmail.com> wrote:

> #199 <https://github.com/leo-editor/leo-editor/issues/199> is

> presently the most serious bug in Leo. Sometimes, but not always,
> cancelling the load of an already-opened .leo file will hard crash
> Leo (Python).
>
> This post is an Engineering Notebook post. It's most notes to myself
> and Terry. Feel free to ignore.
>
> I am studying a core dump on Ubuntu. It's been fun learning about
> apport-retrace

> <http://manpages.ubuntu.com/manpages/vivid/en/man1/apport-retrace.1.html>,
> but not *that *much fun. Terry's analysis of the problem is good

> enough for me. It's time to solve the problem with design, not mere
> code.
>
>
>

> *The original problem*Leo should indeed warn users when they attempt
> to open an already-open file, call it *f.leo*. Saving either copy of
> f.leo could destroy data previously saved in the *other* copy of
> f.leo.
>
> The problem is not actually very serious, because Leo *already *warns

> if f.leo has been changed outside of the presently executing copy of
> Leo. For example, suppose two invocations of Leo exists. Let's call

> them *A* and *B*. Suppose Leo A saves f.leo. Later, if B saves f.leo,

> Leo B will issue a warning that f.leo has been changed outside of B.
>
> Still, I think it is best to warn the user if f.leo is already open.
>
> The mechanism for checking for already-open files is fine. Leo makes
> entries in the global db file when opening a file and deletes entries
> in the db when closing the file. This can lead to spurious "already
> open" messages if Leo is killed rather than being closed normally.
> The db will contain an entry for a .leo file that is not, in fact,
> open. Happily, this has never been a big deal. Furthermore, the
> following scheme handles this case even more smoothly than before.
>

> *Proposal: always open files, even if already open*
>
> Leo will no longer issue *per-file* requests for guidance. Instead,

> Leo will open all possibly-already-open files, putting warnings about

> them in the log. Finally, Leo will raise a *single *warning dialog.

> This dialog will list the files that might already be open, and
> suggest that the user close duplicate files in whatever copy of Leo
> is more convenient.
>
> This scheme solves several problems:
>
> 1. Leo always loads files. This instantly eliminates the possibility
> of hard crashes.
>
> 2. It's faster than the existing scheme. The user only has to
> dismiss the summary dialog.
>

> 3. The user will never have to choose *right now *what action to
> take. Such choices are *always *odious and stressful. Instead, the

> user can choose to close the duplicate f.leo file in either A or B.

> In most cases, it's safe to leave *both* copies open, as long as both

> don't change. To repeat, Leo will issue a warning if that happens.
>
> 4. Closing a duplicate file, in either A or B, automatically clears
> the db entry for that file. There is no need to ask the user whether
> to reset the db!
>
> The only complication will be knowing exactly when/where to issue the
> warning dialog. The details will be different depending on whether
> Leo is loading multiple files at startup, or loading a single file
> later. But this is only a coding detail.
>

> *Summary*

>
> A single dialog that warns about possibly-already-open files is the
> simplest thing that could possibly work:
>
> - It's easy to code.
> - It will stamp out hard crashes.
> - It's simpler, faster, more flexible and less stressful for the user.
>
> Unless there are strong objections to this scheme, I plan to put it
> into effect immediately.
>
> Your comments, please, Amigos.
>
> Edward

> <http://manpages.ubuntu.com/apport-retrace>
>

[Edward K. Ream]

On Sun, Jun 21, 2015 at 12:18 AM, 'Terry Brown' via leo-editor <leo-e...@googlegroups.com> wrote:

​...the use case I have mostly is "yes to all". I.e.

they're not really open elsewhere.  Hmmm, I guess there's nothing to
add to the below to deal with that - the warnings / dialog should say
"this / these outlines *appear* to be open elsewhere" - in my case it
arises from killing Leo accidentally in virtual machines, VNC
connections, dropped X11 forwarding etc.

​Thanks for this comment.  We are on the same page.

I'm wondering what the dialog should say.  There is a temptation to explain about the multiple update problem, etc., but I'm leaning toward just having the dialog say, "The following files may be open in another copy of Leo."

EKR

[Todd Mars]

The thing where it says it's already open when it's not, now I understand it! Where is this global db file and why is it necessary?

thanks

Todd.

[Edward K. Ream]

On Mon, Jun 22, 2015 at 1:37 PM, Todd Mars <tam...@gmail.com> wrote:

The thing where it says it's already open when it's not, now I understand it! Where is this global db file and why is it necessary?

​It's (usually?) in ~/.leo/db/global/open-leo-files  This a binary file (pickleshare).

It's necessary because there is no portable way to determine whether another copy of Leo is running.

EKR

[Todd Mars]

Hi, Why is it needed to know that another copy of Leo is running?

Thanks!

(this kind of thing is fascinating!)

[jkn]

FWIW, I've done this in a cross-platform way by 'allocating' a port number and using a listening socket on that port.

You may not like this for other reasons ... ;-/

    J^n
 

[Terry Brown]

On Thu, 25 Jun 2015 07:23:42 -0700 (PDT)
Todd Mars <tam...@gmail.com> wrote:

> Hi, Why is it needed to know that another copy of Leo is running?
> Thanks!
> (this kind of thing is fascinating!)

Load outline a.leo in Leo instance A, modify, iconify, forget. Now
load outline a.leo (again) in Leo instance B, modify, save, close.
Later, de-iconify Leo instance A, save, close. You just overwrote the
changes you made to the outline in the second loading in instance B.

So it's not really a matter of knowing another instance of Leo is
running, which is fine and so routine it doesn't require any warning,
it's a matter of knowing another Leo has the same outline open already,
and if so issuing a warning. This is achieved by recording which
outlines are open in the global shared database, and warning when an
already open one is loaded again.

I usually experience the flip side of the issue, load some outlines,
rudely hard-kill Leo accidentally (kill a VNC server, break an X11
connection, etc). That means Leo never gets a chance to update the
global db to record that an outline is no longer open (as it would
normally do when Leo exits), so it things it's open elsewhere when it's
not. The spurious warning does no harm in those cases, the lack of a
warning can cause real heartache, as described in first para.

Cheers -Terry

> On Monday, June 22, 2015 at 5:18:01 PM UTC-4, Edward K. Ream wrote:
> >
> > On Mon, Jun 22, 2015 at 1:37 PM, Todd Mars <tam...@gmail.com

> > <javascript:>

[Edward K. Ream]

On Thursday, June 25, 2015 at 4:13:52 PM UTC-5, Terry Brown wrote:

On Thu, 25 Jun 2015 07:23:42 -0700 (PDT)
Todd Mars <tam...@gmail.com> wrote:

> Hi, Why is it needed to know that another copy of Leo is running?

Load outline a.leo in Leo instance A, modify, iconify, forget.  Now
load outline a.leo (again) in Leo instance B, modify, save, close.
Later, de-iconify Leo instance A, save, close.  You just overwrote the
changes you made to the outline in the second loading in instance B.

Thanks, Terry, for this clear explanation.  Much better than mine.

EKR

[Todd Mars]

Hi,

There is kind of a standard way to deal with this problem, already.

1) an option to allow multiple versions of the app to run, or not.  (maybe check if a file exists in the folder you keep your database file in)

2) When refreshing the display, check if a later version of the file exists than what is opened.  (if the stored version is later than the last saved or loaded version)

 If so, ask the user if the user wants to load the later version of the file.

I think this behavior is in Notepad++ which is a good template for what works well for people.

It would be so cool to actually diff the two versions and show the user ....wouldn't it?

(in a separate floating window) Sorry I'm being extraneous.

thanks!

Todd.

[Edward K. Ream]

On Fri, Jun 26, 2015 at 10:38 AM, Todd Mars <tam...@gmail.com> wrote:

Hi,

There is kind of a standard way to deal with this problem, already.

1) an option to allow multiple versions of the app to run, or not.  (maybe check if a file exists in the folder you keep your database file in)

​I know of no easy, cross-platform way of discovering whether two separate instances of Leo are running.  Do you?

EKR