Matt,
> I replicated the only-1-copy-written behaviour here with both @file and
> @clean cloned nodes.
>
Good! I'm not crazy...!
> I Edward explained that he really didn't like cloned
> @file/@thin/@shadow/... nodes because of {...cache problems? race
> conditions?} and possibility of data loss. (whee! I found it)
>
> The advised pattern is to have distinct `@file path1/thing` and `@file
> path2/thing` head nodes and then create an organizer node inside each and
> clone that instead.
>
I tried that, and indeed it works. However, it seems inconsistent that
changing an organizer-node-clone would trigger file writes for all files
containing that clone, but that changing an @file-node-clone would not do
the same.
Further experimentation shows that only the *first* @file-node-clone that
appears (in top-to-bottom traversal order) in the outline actually gets
saved on change - subsequent clones are not saved to their respective
paths. If I exchange the order of the clones in the outline, suddenly a
different file is being saved, but none of the others.
If the reason for not using @file-node-clones is because of the risk of
data loss, then my next question becomes "why is there a risk of data
loss?" If the answer to this is due to some fundamental property of
outlines containing clones, then I'd like to understand that better so that
I can work accordingly. If that is not the case however, then the
underlying cause of data loss should be addressed, rather than to simply
adhere to a convention of not using @file-node-clones.
--
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 [email protected].
To post to this group, send email to [email protected].
Visit this group at https://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.
