[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: corrupt file

From: John Szakmeister <john_at_szakmeister.net>
Date: 2006-10-18 17:19:51 CEST

----- Kristian Berre <Kristian.Berre@mattilsynet.no> wrote:
> I have tried the script posted on
> http://subversion.tigris.org/issues/show_bug.cgi?id=2467, but still
> have
> problems. When I run the script with no options I get:
>
> NodeRev Id: uc.0.r9/1598131
> type: file
> text: INVALID 9 1385989 1244 2640 4e8c272e56a9dbed600f25c5e1bbb4ef
> cpath:
> /fagsystem/matsys/trunk/mt-client/src/main/java/com/computas/mt/ui/virks
> omhet/VirksomhetHeadingVC.java
> copyroot: 0 /
> Invalid rep header found at 1385989 ( )!
> Found problem in NodeRev uc.0.r9/1598131 (1598131)
> text: INVALID 9 1385989 1244 2640 4e8c272e56a9dbed600f25c5e1bbb4ef
> At offset 1385989
>
> After I run the script with -f and run it again with no option I get:
>
>
> NodeRev Id: uc.0.r9/1598131
> type: file
> text: DELTA 9 1385989 1244 2640 4e8c272e56a9dbed600f25c5e1bbb4ef
> cpath:
> /fagsystem/matsys/trunk/mt-client/src/main/java/com/computas/mt/ui/virks
> omhet/VirksomhetHeadingVC.java
> copyroot: 0 /
> starting length: 1240
> offset: 1385995
> size > length
> size: 5
> length: 3
> total: 1237
> remaining: 3
> Traceback (most recent call last):
> File "./fsfsverify.py", line 684, in ?
> process(noderev, rev_file, options.dump_instructions,
> options.dump_windows)
> File "./fsfsverify.py", line 637, in verify
> dump_windows)
> File "./fsfsverify.py", line 274, in verify
> digest = parse_svndiff(f, self.length, dump_instructions,
> dump_windows)
> File "./fsfsverify.py", line 191, in parse_svndiff
> raise "error"
> error
>
> When I run: svnadmin dump repo -r9
> I get: svnadmin: Reading one svndiff window read beyond the end of
> the
> representation
>
> Does anyone know how to fix this?

If you send me a private message with a link to the affected revision file, I can take a look at it. Judging from the error message, the svndiff data still isn't correct, as it's trying to decode an integer beyond the end of the representation.

[snip]
> Does anyone know if the problem less likely to occur in 1.4?

Not necessarily in 1.4.0 (although we did take steps to rule out a few APR-related issues). Malcome committed a potential fix for inclusion in 1.4.1, but it still needs testing, and I only know of one person who has been able to cause the problem to occur repeatedly.

-John

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Wed Oct 18 17:21:02 2006

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.