Heads Up - My Workbook Is Getting Destroyed

[Thomas Passin]

I haven't filed an issue on this yet because I haven't got all the conditions nailed down.  But Leo has been replacing my workbook with the default CheatSheet ... sometimes.  Please make sure you have a backup copy until this gets resolved.

I noticed this behavior while I was testing code with the branch 

Leo 6.7.4-devel, ekr-3181-mypy-links branch, build b9a9205ae9

This is the branch with with all the new unl code.  I'm not sure if it can also occur on the devel branch.

The problem is that this behavior seems to happen suddenly.  Once it starts, every time I launch Leo with this command line, the workbook.leo outline gets replaced:

py -m leo.core.runLeo

If I include the name of the outline the outline does not get replaced:

py -m leo.core.runLeo .leo\workbook.leo

When the outline gets replaced, I noticed that the other outlines that were opened previously did not get opened.  This made me think that the database was getting corrupted.  But I deleted the .leo\db directory and the workbook still got deleted.

I think that something the the experimental branch is corrupting some string, maybe of the recent files list.  This prevents Leo from finding the workbook.  So it creates a new one.  I have observed that changing back to the devel branch does not stop this behavior on the first launch, but after I run Leo once in devel and then restore the workbook from backup, after that Leo behaves normally and does not replace the workbook.  When I switch back to the experimental branch, that's when this problem starts happening again.

I suggest that if Leo cannot find the workbook when it wants to open it, it should notify the user that it can't find it and ask if it should create a default workbook.  The user will probably say "no!" since they will know that they want to keep the existing one.

Of course, the problem should be fixed, but this would prevent the loss of the workbook in case of future bugs as well.  I don't know about you, but I have a lot of work in my workbook that I really don't want to lose.

I was saved by Leo's new automatic backup, so I had a workbook.leo.bak file when I first realized realized the problem. (Yes, I do back up the .leo directory, but not recently enough this time).

[Thomas Passin]

I've done more testing, and the pattern is definitely repeatable.  If I check out the  ekr-3181-mypy-links branch, the first time I launch Leo the workbook may not be affected but every time after that it is destroyed and replaced by the default CheatSheet.  When I change back to the devel branch, the first launch after that also replaces the workbook, but after that the workbook is opened without replacement.  Remember, in these trials after each time the workbook gets replaced, I restore it from backup for the next launch.

The replacement does not happen if I specify the workbook on the command line.  Clearing the recent files list had no effect on the behavior.  Nether did deleting the .leo\db directory.

[Edward K. Ream]

On Wed, Jun 28, 2023 at 10:27 AM Thomas Passin <tbp1...@gmail.com> wrote:

I've done more testing, and the pattern is definitely repeatable.  If I check out the  ekr-3181-mypy-links branch, the first time I launch Leo the workbook may not be affected but every time after that it is destroyed and replaced by the default CheatSheet.  When I change back to the devel branch, the first launch after that also replaces the workbook, but after that the workbook is opened without replacement.  Remember, in these trials after each time the workbook gets replaced, I restore it from backup for the next launch.

The replacement does not happen if I specify the workbook on the command line.  Clearing the recent files list had no effect on the behavior.  Nether did deleting the .leo\db directory.

Thanks for this report.  Please file an issue, if you haven't done so. This issue will have high priority.

Edward

[jkn]

FWIW, I have a vague feeling that something like this happened to me a few months ago. It only occurred the once, and I am not 100% sure what happened, but it definitely involved the CheatSheet 'appearing'.

Only mentioning it because this would have been before the recent work.

J^n

[Thomas Passin]

On Wednesday, June 28, 2023 at 12:52:42 PM UTC-4 jkn wrote:

FWIW, I have a vague feeling that something like this happened to me a few months ago. It only occurred the once, and I am not 100% sure what happened, but it definitely involved the CheatSheet 'appearing'.

Only mentioning it because this would have been before the recent work.

I did too, but it didn't repeat and I couldn't find a way to induce it.

[Thomas Passin]

Done: #3404

[Jacob Peck]

I'd like to propose that *any* data corruption issue at all in Leo should be reported, regardless of whether the steps to replicate are known.  The last thing an editor should ever do is destroy data.

Jake

--
You received this message because you are subscribed to the Google Groups "leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email to leo-editor+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/leo-editor/e337e8c2-ba2f-46c3-9780-0154dc9e5e9en%40googlegroups.com.

[Thomas Passin]

I agree, but with a non-reproducible report it's hard to make any progress.  In this case I wanted to be able to file a more definite issue, but also alert people as soon as possible to back up their workbooks until the thing gets resolved.  

I do think that one defensive code change to make is for Leo never to replace the workbook - whether or not it can find it - without asking the user.  On first use, when the Leo user gets created, that wouldn't apply.

[Edward K. Ream]

On Wed, Jun 28, 2023 at 3:15 PM Thomas Passin <tbp1...@gmail.com> wrote:

one defensive code change to make is for Leo never to replace the workbook - whether or not it can find it - without asking the user.  On first use, when the Leo user gets created, that wouldn't apply.

Good idea.

Edward

[Edward K. Ream]

On Tuesday, June 27, 2023 at 4:55:37 PM UTC-5 Thomas wrote:

> I haven't filed an issue on this yet because I haven't got all the conditions nailed down. 

See #3404. The first comment of the issue discusses the failure and how to fix it.

The short version: Leo's startup code should not use unls! The fix should be straightforward.

PR #3215 may as well clean up the mess.

Edward

[Edward K. Ream]

On Thursday, June 29, 2023 at 2:10:26 AM UTC-5 Edward K. Ream wrote:

 

See #3404. The first comment of the issue discusses the failure and how to fix it.

...

PR #3215 may as well clean up the mess.

On second thought, a new PR will make testing easier, even if the new PR eventually gets merged into PR #3215.

Edward

[Edward K. Ream]

On Thursday, June 29, 2023 at 3:43:22 AM UTC-5 Edward K. Ream wrote:

> See #3404. The first comment of the issue discusses the failure and how to fix it.

> PR #3215 may as well clean up the mess.

>> On second thought, a new PR will make testing easier...

My first thought was correct. All work must be done in PR #3215. Only that PR has the new methods.

Edward

[Thomas Passin]

Even though I dislike PRs that are very complicated and try to do too many things, I have to agree in this case.

[Edward K. Ream]

On Thu, Jun 29, 2023 at 4:41 PM Thomas Passin <tbp1...@gmail.com> wrote:

Even though I dislike PRs that are very complicated and try to do too many things, I have to agree in this case.

Thanks :-)

Edward