You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Philip Martin <ph...@codematters.co.uk> on 2018/03/16 13:44:18 UTC
Re: E130003: The XML response contains invalid XML - Follow-up
"NOCERA, ANDY" <an...@att.com> 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 correct this
> ourselves without a dump and load?
>
> db/revs/0/1 /usr/tmp/xrepox/db/revs/0/1
> diff db/revs/0/1 /usr/tmp/xrepox/db/revs/0/1
> 18c18
> < text: 1 76 48 0 ec69809945c46f2bb74e99a3ff7cd917
> ---
> > text: 1 76 48 48 ec69809945c46f2bb74e99a3ff7cd917
> 22c22
That looks like issue 4554
https://issues.apache.org/jira/projects/SVN/issues/SVN-4554
Editing the file is unlikely to work. Later revisons refer to data in
earlier revisions via a byte offset into the earlier file. When you
edit "0" to "48" you have changed the byte offset of all the data beyond
the edit and that breaks the references in all the later files. You
would need to identify all the affected offsets in later files and
modify them, which in turn may lead to more offset changes. You may
need to recompute some checksums as well.
--
Philip
Re: E130003: The XML response contains invalid XML - Follow-up
Posted by Johan Corveleyn <jc...@gmail.com>.
On Fri, Mar 16, 2018 at 4:57 PM, Philip Martin <ph...@codematters.co.uk> wrote:
> Daniel Shahaf <d....@daniel.shahaf.name> writes:
>
>> Philip Martin wrote on Fri, 16 Mar 2018 13:44 +0000:
>>
>> Changing "0" to "48" would also have broken the <root-offset> and
>> <cp-offset> 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. That works because the change is after <root-offset> but before
> <cp-offset> and he shows <cp-offset> changing as well.
>
> I guess you can get away with editing the last node in the file provided
> you also change <cp-offset> in the same file.
Does that also explain why the OP could repair some repositories by
simply dumping and loading them? Or would dump+load also work for
corruption-instances that are not on the root node?
From the perspective of the recoveries done by the OP, this doesn't
seem like a "breaking corruption", since it can be recovered from
quite easily.
If that is not the case, and some unrecoverable instances remain (that
cannot be dumped+loaded), can we offer any other suggestions to
recover?
--
Johan
Re: E130003: The XML response contains invalid XML - Follow-up
Posted by Philip Martin <ph...@codematters.co.uk>.
Daniel Shahaf <d....@daniel.shahaf.name> writes:
> Philip Martin wrote on Fri, 16 Mar 2018 13:44 +0000:
>
> Changing "0" to "48" would also have broken the <root-offset> and
> <cp-offset> 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. That works because the change is after <root-offset> but before
<cp-offset> and he shows <cp-offset> changing as well.
I guess you can get away with editing the last node in the file provided
you also change <cp-offset> in the same file.
--
Philip
Re: E130003: The XML response contains invalid XML - Follow-up
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
Philip Martin wrote on Fri, 16 Mar 2018 13:44 +0000:
> "NOCERA, ANDY" <an...@att.com> 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 correct this
> > ourselves without a dump and load?
> >
> > db/revs/0/1 /usr/tmp/xrepox/db/revs/0/1
> > diff db/revs/0/1 /usr/tmp/xrepox/db/revs/0/1
> > 18c18
> > < text: 1 76 48 0 ec69809945c46f2bb74e99a3ff7cd917
> > ---
> > > text: 1 76 48 48 ec69809945c46f2bb74e99a3ff7cd917
> > 22c22
>
> That looks like issue 4554
>
> https://issues.apache.org/jira/projects/SVN/issues/SVN-4554
>
> Editing the file is unlikely to work. Later revisons refer to data in
> earlier revisions via a byte offset into the earlier file. When you
> edit "0" to "48" you have changed the byte offset of all the data beyond
> the edit and that breaks the references in all the later files.
Changing "0" to "48" would also have broken the <root-offset> and
<cp-offset> offsets in that revision file, so how come 'verify' worked after
that change?
Cheers,
Daniel
(The <foo-offset> terms are from the 'structure' file and describe
format 6; format 7 has <l2p offset> and <p2l offset> which are
analogous)