New write code now in devel

[Edward K. Ream]

PR #4418 contains important improvements to Leo's read/write code.

Félix remains skeptical that it works in all cases.

I haven't heard from him in over a week. In the absence of further comments I think the benefits of wider testing outweigh any remaining problems.

Please keep testing devel and report any problems.

Edward 

[Félix]

I've pulled devel and re-tested: The bug is still occuring, and I've found another smaller one.

Here's how to reproduce that first bug (in 3 steps)

1- In a new Leo file, create an @clean test.txt with some body text and save.  (The resulting .leo file contains mod_time UAs)

2- Close Leo, edit the test.txt file manually, and Re-Open Leo...  Observe that your external file changes were picked up. (all OK so far)

3- Save the leo file without editing (important!) to trigger the bug -> The resulting .leo has no mod_time UA.

(But if you edited even slightly the leo file before saving, the UAs will be written normally)

Here's how to reproduce the other bug:

(same step 1 as first example above) instead of closing leo completely at step 2, if you instead just close the tab (and thus keeping Leo opened by having more than one tab opened with some other .leo file)

...and then complete the rest of the actions for step 2: edit the external file 'test.txt' and re-open that .leo file's tab ...

(at the end of step 2, before step 3) -> Upon opening that tab for this .leo file, Leo will ask you if you want to reload that @clean from disk (as if it was a 'live' file change when Leo is already opened) screenshot: 

Note that you can see underneath that dialog that the @clean body was already refreshed with the new external file content. and that responding yes or no does not do any difference. (the new content is used)

(From what I remember of using @clean nodes for many years, I think it should just reload the new @clean file content without asking, just like when opening it along with leo itself)

I'll easily show you those 2 bugs explicitly by sharing my screen in a zoom if those two descriptions on how to reproduce them are not clear. :)

Félix

[jkn]

Hi Felix

    when you talk about 'mod_time UA', are you talking about eg. the time(s) reported by the linux 'stat' command - last access time, last modify time, etc (or the Windows equivalent)?

I ask for a couple of reasons:

1) I would have expected that these were dealt with by the underlying OS - having a file with no "mod_time" seems very odd, unless I am misunderstanding

2) separate to this, I have been having a bit of trouble with the Seafile "file sharing" facility I run on my local network. I am occasionally seeing an issue with my shared .leo files not being synchronised and I am wondering if there is a connection. More likely to be a Seafile issue, but you never know...

    Regards

    J^n

[jkn]

Update: I've taken a look at the PR and seen that the 'mod_time VA' is not related to the mtime file attribute I was talking about above. Apologies for the noise.

    J^n

[Edward K. Ream]

On Mon, Aug 18, 2025 at 10:25 PM Félix <felix...@gmail.com> wrote:

I've pulled devel and re-tested: The bug is still occuring, and I've found another smaller one.

Here's how to reproduce that first bug (in 3 steps)

Thanks for this testing.  I'll fix the remaining bugs in a new PR.

Edward

[Edward K. Ream]

On Mon, Aug 18, 2025 at 10:25 PM Félix <felix...@gmail.com> wrote:

I've pulled devel and re-tested: The bug is still occuring, and I've found another smaller one.

I think a zoom call would be wise. What time would you like?

Edward