You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by "Kutter, Martin" <ma...@siemens.com> on 2010/02/25 12:29:08 UTC

Corrupted FSFS commit

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.kutter@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
 

Re: AW: Corrupted FSFS commit

Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
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

AW: Corrupted FSFS commit

Posted by "Kutter, Martin" <ma...@siemens.com>.
> 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

AW: Corrupted FSFS commit

Posted by "Kutter, Martin" <ma...@siemens.com>.
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

Re: Corrupted FSFS commit

Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
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).

> 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.kutter@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
>  
>