Mailing-List: contact users-help@subversion.apache.org; run by ezmlm
Precedence: bulk
Received-SPF: pass (athena.apache.org: local policy includes SPF record at
 spf.trusted-forwarder.org)
Reply-To: <sstadler@incircuits.com>
From: "Steven Stadler" <sstadler@incircuits.com>
To: <users@subversion.apache.org>
Subject: Corrupt Node - revision '0.0.r528/72560508'
Date: Sun, 9 Mar 2014 12:51:39 -0500
Organization: InCircuits, Inc.
Message-ID: <002d01cf3bc0$39d53f30$ad7fbd90$@incircuits.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
Thread-Index: Ac87v/JUHiMSASRVS86N2Kcrw5hstw==
Content-Language: en-us

The person from the CollabNet forum suggested posting this here, 

" It might make sense to post this on the users at subversion dot apache dot
org list. I have seen developers offer to look at corrupt revision files and
fix them by hand if possible."

Thank You,

Steve


Corrupt Node - revision '0.0.r528/72560508' 


Author
sstadler (OCN Member) 
Full name
Steven Stadler 
Date
2014-03-09 08:42:06 PDT
Message
I had a hard drive failure, where the drive reported that the data should
not be corrupt. I ordered new drives, and while putting my data on to the
new drives I found that two of my SVN db files were corrupt, and my
automatic backup had run so the backup was corrupt as well.

I run verify, and the report indicates that revision 528 is corrupt.

I have a backup dump for 0:597.

I tried to make a dump for 598:665 so I could use those two dumps to make a
new repository, but it does not do anything? Maybe there is also a corrupt
revision within 598:665? How do I verify a range following a corrupt
revision?

If I load the backup dump for 0:597, will it overwrite revisions 0:597, and
keep the rest 598:665?

Can I just load or recover revision 528 from a dump?

Thank You, 


Author
markphip (OCN Member)  

Full name
Mark Phippard  

Date
2014-03-09 09:02:35 PDT 

Message
On Mar 9, 2014, at 11:42 AM, Steven Stadler <sstadler at incircuits dot com>
wrote:

> I had a hard drive failure, where the drive reported that the data should
not be corrupt. I ordered new drives, and while putting my data on to the
new drives I found that two of my SVN db files were corrupt, and my
automatic backup had run so the backup was corrupt as well.
> 
> I run verify, and the report indicates that revision 528 is corrupt.

It might make sense to post this on the users at subversion dot apache dot
org list. I have seen developers offer to look at corrupt revision files and
fix them by hand if possible.

> 
> I have a backup dump for 0:597.
> 
> I tried to make a dump for 598:665 so I could use those two dumps to make
a new repository, but it does not do anything?

What do you mean by that? Did you add the --incremental option when you ran
this?

> Maybe there is also a corrupt revision within 598:665? How do I verify a
range following a corrupt revision?

Did you try this?

$ svnadmin verify -r 598:HEAD /path/to/repos

> If I load the backup dump for 0:597, will it overwrite revisions 0:597,
and keep the rest 598:665?

No. You could only load that dump file into a new, empty repository. So you
would need that second dump file, made with the --incremental option, so
that you could load the rest of the revisions.

> Can I just load or recover revision 528 from a dump?

If it came to that, you would probably need to load the entire repos from
the dump file.

You could try creating a new empty repository and load your dump file into
it. Then compare the revision files for r528. It might be possible to just
copy those files into the old repository. It will depend a lot on using the
same version of SVN though. One of the reasons people dump/load is that the
on-disk format "improves" with new releases by using newer techniques for
storing the data. So if you are loading the repository with a newer version
of SVN than created the original repository, it is unlikely you could simply
"drop" a revision file from the new version to the old one. That technique
is not supported anyway, I am just saying it might be possible and might
work.

The revision files are stored in the db/revs and db/revprops folders. So
look for: db/revs/0/528 and db/revprops/0/528

If you have a really old repository format, then the /0/ folder will not be
there.

Mark  


Author
sstadler (OCN Member)  

Full name
Steven Stadler  

Date
2014-03-09 09:55:42 PDT 

Message
Thanks Mark!!

I tried making a new repository from the dump 0:597, and I copied the files
from the db\revs and db\revprops for 528 from the new repository to the old
one, where the 528 file in the old db\revs had a very different file size
than the new one.

The repository still does not verify and it says that revision 527 is now
corrupt, it has a malformed header.

I was thinking about copying over 527, and see if 526 will then be bad?? but
527 was good before copying over 528?

I should post this on subversion dot apache dot org list before I make
things worse....

I also tried making a dump of 598:665 selecting the incremental check box,
and it still did not make a dump??

I also tried svnadmin verify -r 598:HEAD /path/to/repos and it returns Can't
read length in line in file /path/to/repos \db\revs\528

Is there a way to forward this thread to the users at subversion dot apache
dot org list?

Thanks again,

Steve  


Author
sstadler (OCN Member)  

Full name
Steven Stadler  

Date
2014-03-09 10:04:30 PDT 

Message
just another not,

I just tried to make a dump of 598:665 from the CMD window instead if from
the CollabNet web interface, and the dump returns the same error as the
verify, Can't read length in line in file /path/to/repos \db\revs\528  


Steven R Stadler  PE
InCircuits Inc
4284 Reiland Lane
Shoreview MN  55126

Tel  651 765 4225
Fax  651 765 4226
Cell  651 492 9792

sstadler@incircuits.com
www.incircuits.com