Corrupted FSFS commit

[Kutter, Martin]

Hello,

I got a strange error in one of our subversion repositories: On checking
out a file from revision 3865 on, svn reports "Svndiff contains a too-large window".

The same error is reported by "svnadmin verify" and "svnadmin dump".

Server OS is RedHat Enterprise Linux 5.4 (64 bit)
Subversion server is 1.6.5 built from a slightly modified the Fedora Core 12 Source RPM
using the sqlite amalgamation
SVN client used was TortoiseSVN 1.6.6 (probably on XP, not sure)
Repository type is FSFS
Repository layout is sharded
The repository as a hole has a size of around 5GB
db/revs/7/3865 is 210MB in size, a backup of the file from the night after the
commit contains a file with no differences.

The revision in question contains two added binary files of around 102MB in size.
The file which cannot be checked out is one of these files.
All other files added or updated in this revision can be checked out.

In the current state, the repository cannot be dumped - when reaching the corrupted
revision, svnadmin aborts with "Svndiff contains a too-large window".

Is there some way to recover the checked-in file?
Can the file in question be removed from this revision?
Or can the complete revision be replaced somehow?

Thanks a lot,

Martin Kutter

Siemens AG
Siemens IT Solutions and Services
Global Operations
SIS GO CS ITO A&S 4
Werner-von-Siemens-Str. 60
91052 Erlangen, Germany
mailto:martin...@siemens.com

Siemens Aktiengesellschaft: Chairman of the Supervisory Board:
Gerhard Cromme; Managing Board: Peter Loescher, Chairman, President and Chief
Executive Officer; Wolfgang Dehen, Heinrich Hiesinger, Joe Kaeser, Barbara Kux,
Hermann Requardt, Siegfried Russwurm, Peter Y. Solmssen; Registered offices:
Berlin and Munich, Germany; Commercial registries: Berlin Charlottenburg,
HRB 12300, Munich, HRB 6684; WEEE-Reg.-No. DE 23691322

[Daniel Shahaf]

Kutter, Martin wrote on Thu, 25 Feb 2010 at 13:29 +0100:
> Hello,
>
> I got a strange error in one of our subversion repositories: On checking
> out a file from revision 3865 on, svn reports "Svndiff contains a too-large window".
>

This is the error message added in 1.6.4 as part of the security fix
then. You may want to try a 1.6.3 server (the last release *without*
the security fix).

[Kutter, Martin]

Daniel Shahaf wrote:
> Kutter, Martin wrote on Thu, 25 Feb 2010 at 13:29 +0100:
> > I got a strange error in one of our subversion
> > repositories: On checking
> > out a file from revision 3865 on, svn reports "Svndiff
> > contains a too-large window".
>
> This is the error message added in 1.6.4 as part of the security fix
> then. You may want to try a 1.6.3 server (the last release *without*
> the security fix).

This is what I found on the web on this message. However, the commit
was performed using client and server >= 1.6.4, and a modified svnadmin
(reporting the numbers checked along with the error message) clearly
shows some kind of overflow: The reported numbers are unstable, and
flip between positive and negative values.
Testing with 1.6.3, which has the security error, seems not very
appealing: First, I think that the error should have been reported
on commit, not on checkout. Moreover, it's quite unlikely that 1.6.3
will be able to handle the revision file correctly - it's much more
likely that the revision will trigger the security error.

I'm afraid the commit just got corrupted somehow - is there a way to
remove/replace it in the repository?

Regards,

Martin

[Kutter, Martin]

> Daniel Shahaf wrote:
> Kutter, Martin wrote on Thu, 25 Feb 2010 at 13:29 +0100:
> > I got a strange error in one of our subversion
> > repositories: On checking
> > out a file from revision 3865 on, svn reports "Svndiff
> > contains a too-large window".
>
> > This is the error message added in 1.6.4 as part of the security fix
> > then. You may want to try a 1.6.3 server (the last release
> *without*
> > the security fix).

A subversion 1.6.3 svnadmin yields:

@> ./svnadmin-1.6.3 dump /repo -r 3865 > 3865.svndump
Aborted
@>

The resulting (aborted) dump file is 71072278 bytes, the one
from a 1.6.5 svnadmin is 71072237 bytes long

Martin

[Daniel Shahaf]

Kutter, Martin wrote on Fri, 26 Feb 2010 at 10:29 +0100:
> The reported numbers are unstable, and flip between positive and
> negative values.

They don't have any reason to differ across runs, do they? So, what's
next? Uninitialized memory? Valgrind? (and how to make it play nicely
with pools, I don't rememeber)

> First, I think that the error should have been reported
> on commit, not on checkout.

You can run verify/dump automatically on every commit to help catch
these errors.

> I'm afraid the commit just got corrupted somehow - is there a way to
> remove/replace it in the repository?

If 1.6.5 dumps without aborting, I suppose you could dump/load with
svndumpfilter to remove the added path. Or you could configure authz
rules to prevent you from seeing the 'problematic' added path, and then
run svnsync as usual (it would ignore paths that aren't authz-readable
for it).

Daniel