On Fri, Mar 16, 2018 at 4:57 PM, Philip Martin wrote:
> Daniel Shahaf writes:
>
>> Philip Martin wrote on Fri, 16 Mar 2018 13:44 +:
>>
>> Changing "0" to "48" would also have broken the and
>> offsets in that revision file, so how come 'verify' worked after
>> that change?
>
> In the exampl
Daniel Shahaf writes:
> Philip Martin wrote on Fri, 16 Mar 2018 13:44 +:
>
> Changing "0" to "48" would also have broken the and
> offsets in that revision file, so how come 'verify' worked after
> that change?
In the examples he gave it looks like the root node itself is being
edited. Th
Philip Martin wrote on Fri, 16 Mar 2018 13:44 +:
> "NOCERA, ANDY" writes:
>
> > I used dump and load to debug the malformed node revision ID. Here
> > are my steps and what learned. Looks like the revs' file text: entry
> > has a zero instead of size. By just editing the size, verify worke
"NOCERA, ANDY" writes:
> I used dump and load to debug the malformed node revision ID. Here
> are my steps and what learned. Looks like the revs' file text: entry
> has a zero instead of size. By just editing the size, verify worked.
> No other change was required. The question is can we corr
[ cc += dev@ ]
NOCERA, ANDY wrote on Thu, 15 Mar 2018 22:35 +:
> Folks,
>
> I used dump and load to debug the malformed node revision ID. Here are
> my steps and what learned. Looks like the revs' file text: entry has
> a zero instead of size.
To be clear, you mean the fourth field.
Folks,
I used dump and load to debug the malformed node revision ID. Here are my
steps and what learned. Looks like the revs' file text: entry has a zero
instead of size. By just editing the size, verify worked. No other change
was required. The question is can we correct this ourselve