On Tue, Jun 14, 2011 at 7:53 PM, Gregory Crosswhite
<email address hidden> wrote:
> To experience this for yourself, try opening either of the attached
> files which contain examples of cases where the tangler can fail, and
> change file to @file. Save and quit Leo, and then open the file again.
> If you still see the children and content in bug.py, make a trivial
> change to it (to make bug.py dirty), save, quit, and open it again.
> Repeat this process a few times and you will eventually see that bug.py
> no longer has any content! The bug is nondeterministic, so sometimes
> its contents are lost on the first save (i.e., just after changing file
> to @file), sometimes it takes many iterations of this process for the
> contents to be lost.
I do not believe for a moment that this bug is "nondeterministic".
Rather, it depends on a certain sequence of actions.
At the code level, the bug will happen if and only if forceWrite is
computed to be False in fc.putVnode. I just saw the bug in action: it
involved me saving an "improper" outline several times. I knew I
would lose data when I saw the trace of forceWrite go from True to
False.
I suspect, but do not know for sure, that forceWrite goes to False
because some part of the write logic has cleared root's orphan bit.
On Tue, Jun 14, 2011 at 7:53 PM, Gregory Crosswhite
<email address hidden> wrote:
> To experience this for yourself, try opening either of the attached
> files which contain examples of cases where the tangler can fail, and
> change file to @file. Save and quit Leo, and then open the file again.
> If you still see the children and content in bug.py, make a trivial
> change to it (to make bug.py dirty), save, quit, and open it again.
> Repeat this process a few times and you will eventually see that bug.py
> no longer has any content! The bug is nondeterministic, so sometimes
> its contents are lost on the first save (i.e., just after changing file
> to @file), sometimes it takes many iterations of this process for the
> contents to be lost.
I do not believe for a moment that this bug is "nondeterministic".
Rather, it depends on a certain sequence of actions.
At the code level, the bug will happen if and only if forceWrite is
computed to be False in fc.putVnode. I just saw the bug in action: it
involved me saving an "improper" outline several times. I knew I
would lose data when I saw the trace of forceWrite go from True to
False.
I suspect, but do not know for sure, that forceWrite goes to False
because some part of the write logic has cleared root's orphan bit.
Edward