r5148 can overwrite files on disk

[zpcspm]

I have just bumped into an unusual situation and I want to share it to get some feedback.

I've opened an old pet project of mine (last commit was 2011-06-20 so it's been a while).  It consists of a leo outline (let's call it outline.leo for convenience) + a src/ directory which contains a source code file (let's call it code.py)

outline.leo has this in its header:

<leo_header file_format="2"

Outline structure is pretty simple: I have a "@path src" node for the src directory and a "@thin code.py" subnode of it.

Here is what I see in log pane when I'm opening outline.leo (I will be replacing long absolute paths with relative ones for convenience):

--- snip ---

reading: outline.leo

reading: @thin code.py

No @+leo sentinel in: src/code.py

can not read 3.x derived file src/code.py

you may upgrade these file using Leo 4.0 through 4.4.x

--- snip ---

First thing I did was to have a look at code.py. It had no setinels in it indeed, but frankly, I forgot why. If the last two lines are related to it - fine, though the hint about upgrading file is not understandable.

But well, I remember leo has shadow files, so I thought I may try getting code.py into outline that way. I replaced "@thin code.py" with "@shadow code.py". Obviously, I had to save changes. This is what I saw in log pane:

--- snip ---

created directory: src/.leo_username

created: src/.leo_username/xcode.py

wrote:     src/code.py

saved: outline.leo

--- snip ---

No confirmation dialog was displayed. I looked at code.py externally after that and was surprised to see... that it was empty! Now, I have some settings in myLeoSettings.leo, but I'm pretty sure there's nothing that looks like explicit disabling of confirmation dialog when writing files and there's a risk of overwriting some and get data loss.

Summary:

1. My workflow was dictated by common sense, yet I got data loss. If I did something weird, please point me to it.

2. No real data loss occurred - I had all my files in version control so I just checked out latest revision into workspace (I'm using fossil as version control for this project but this is probably totally irrelevant).

3. I could probably repeat the workflow, save outline (and get code.py deleted again), then restore code.py from repository and restart leo to see if it gets slurped into the outline by @shadow, but this looks like an ugly hack so I decided to ask here first.

Your comments please.

[Edward K. Ream]

On Fri, Mar 16, 2012 at 7:51 PM, zpcspm <zpc...@gmail.com> wrote:

> I replaced "@thin code.py" with "@shadow code.py".

Oh my. You are asking for loads of trouble do this.

Asking Leo to detect this change borders on completely unreasonable.
The relevant code is very complex, and making it even more complex to
handle this situation has no appeal: it could easily make things much
worse in more common situations.

Why not simply use the import command to recreate your code?

Edward

[zpcspm]

On Saturday, March 17, 2012 2:26:55 PM UTC+2, Edward K. Ream wrote:

On Fri, Mar 16, 2012 at 7:51 PM, zpcspm wrote:

> I replaced "@thin code.py" with "@shadow code.py".

Oh my.  You are asking for loads of trouble do this.

My confusion about deleted content in code.py comes from the assumption that since I didn't modify the content of code.py explicitly - I was expecting leo to not modify it behind the curtain. I didn't use shadow files extensively, but I always saw creating shadow nodes as "symlinking" external files into an outline. Ok, it would be fine to get their content changed, but only if I would do it explicitly (which I didn't). Are these assumptions of mine flawed somehow?
 

Why not simply use the import command to recreate your code?

 This option just didn't cross my mind, I have tried it now and here's my feedback:

- leo added a "@language unknown_language" at the top of imported code.py, even if first line of it starts with "#!/usr/bin/env python". I am not sure this has any negative implications, since at least code highlight works and indentation wasn't broken
- leo added the imported file as "@file" node with absolute path. I am a bit worried about how would this work for larger projects with multiple files. Wouldn't the outline structure get broken if the working directory is moved to another place (another directory, eventually another computer)? Of course this is pure speculation without trying, but after shooting myself in the foot once, I'd rather ask than try something else that "makes sense".
- leo added the imported file as single node, didn't put each function into its own subnode

I am still leaning towards trying the ugly hack instead (the one that I mentioned in my previous post).

And I want to emphasize that this is not a feature request that should make leo work as I want in my particular case. I am rather trying to avoid getting a bad habit (replacing @thin nodes with @shadow ones), since this proved to be a wrong approach due to data loss.

[Edward K. Ream]

On Sat, Mar 17, 2012 at 8:25 AM, zpcspm <zpc...@gmail.com> wrote:

> And I want to emphasize that this is not a feature request that should make leo work as I want in my particular case. I am rather trying to avoid getting a bad habit (replacing @thin nodes with @shadow ones)

Rev 5153 now suggests using Leo's import command. Perhaps that will
be enough to guide you and others in a more reasonable direction.

Edward