From users-return-4097-daniel=haxx.se@subversion.apache.org Tue Aug 3 21:49:33 2010 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on giant.haxx.se X-Spam-Level: X-Spam-Status: No, score=-1.5 required=3.0 tests=BAYES_00,T_RP_MATCHES_RCVD autolearn=ham version=3.3.1 Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by giant.haxx.se (8.14.3/8.14.3/Debian-9.1) with SMTP id o73JnVvE008331 for ; Tue, 3 Aug 2010 21:49:32 +0200 Received: (qmail 29008 invoked by uid 500); 3 Aug 2010 19:49:22 -0000 Mailing-List: contact users-help@subversion.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Delivered-To: mailing list users@subversion.apache.org Received: (qmail 29001 invoked by uid 99); 3 Aug 2010 19:49:22 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 03 Aug 2010 19:49:22 +0000 X-ASF-Spam-Status: No, hits=-2.3 required=10.0 tests=RCVD_IN_DNSWL_MED,SPF_PASS Received-SPF: pass (nike.apache.org: local policy) Received: from [34.254.247.12] (HELO NP1MAIL002.halliburton.com) (34.254.247.12) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 03 Aug 2010 19:49:12 +0000 Received: from np1exhu011.corp.halliburton.com (np1exhu011.corp.halliburton.com [34.34.132.81]) by NP1MAIL002 (8.14.3/8.14.3) with ESMTP id o73JlqT0014929 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Tue, 3 Aug 2010 14:48:51 -0500 Received: from NP1EXMB016.corp.halliburton.com ([34.34.132.177]) by np1exhu011.corp.halliburton.com ([34.34.132.81]) with mapi; Tue, 3 Aug 2010 14:48:36 -0500 From: Justin Georgeson To: Justin Georgeson CC: "users@subversion.apache.org" Date: Tue, 3 Aug 2010 14:48:34 -0500 Subject: RE: corrupt revision, "Reading one svndiff window read beyond the end of the representation" Thread-Topic: corrupt revision, "Reading one svndiff window read beyond the end of the representation" Thread-Index: AcszGIVCEyqiq52VTXCK1Kh+TbKB9AAA+xZgAAbSioAAAV9/kAABvIQQ Message-ID: References: <20100803142936.GC17130@daniel3.local> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.0.10011,1.0.148,0.0.0000 definitions=2010-08-03_07:2010-08-03,2010-08-03,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=5.0.0-1005130000 definitions=main-1008030148 X-Virus-Checked: Checked by ClamAV on apache.org X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.3.5 (giant.haxx.se [80.67.6.50]); Tue, 03 Aug 2010 21:49:33 +0200 (CEST) X-Friend: Nope Think I have it fixed now. In case this is helpful to anyone else, here's t= he final set of diffs from the original corrupt rev file and the now workin= g copy. Thanks for the help! [svnadmin@hourdcm1 ~]$ diff cm3-39245 39245 20c20 < text: 39008 0 820 34402 b0823a9c03c803b37b5adc33430cc796 f310eb9358578507= ca831265f855ba972af6ca23 39244-uc7/_9 --- > text: 39014 0 820 34402 b0823a9c03c803b37b5adc33430cc796 f310eb9358578507= ca831265f855ba972af6ca23 39244-ua4/_9 441c441 < dir 7-29081.0-38388.r38584/540 --- > dir 6-29081.0-38388.r38584/540 1028c1028 < text: 39245 2144 10888 10888 789605216a8f727194ed4fde84f17a12 --- > text: 39245 2144 10888 10888 67364687e6d64ee34f5d21aa9ab3d76c 1242c1242 < dir 5-24766.0.r38038/4016 --- > dir 4-24766.0.r38038/4016 1273c1273 < text: 39245 15409 654 654 6eca19e967a74255e570ca8b067af7c8 --- > text: 39245 15409 654 654 236f0e0057d1777e4bffe306c9753b77 1544c1544 < pred: 0.0.r39244/52342 --- > pred: 0.0.r39244/52346 1551c1551 < e-17515.0-38388.t39244-uc7 modify-file true true /branches/branch_5000_0_= 2_0/port/com/lgc/prowess/tool/input/SmartInputProc.java --- > e-17515.0-38388.t39244-ua4 modify-file true true /branches/branch_5000_0_= 2_0/port/com/lgc/prowess/tool/input/SmartInputProc.java -----Original Message----- From: Justin Georgeson=20 Sent: Tuesday, August 03, 2010 2:26 PM To: Justin Georgeson Cc: users@subversion.apache.org Subject: RE: corrupt revision, "Reading one svndiff window read beyond the = end of the representation" After a series of changing the node-revision and checksum errors I now have= a revision file in the backup repo that I verifies and I can checkout head= of that branch and do a diff on that revision. However, I can't do a log o= n that revision yet [svnadmin@hourdcm1 input]$ svn log -r 39245 svn: Corrupt node-revision '8g-3.0-38388.r38555/8238' svn: Found malformed header in revision file I'm going to save a copy of the current rev file and keep on plugging away = at these node-revision/checksum errors and hopefully end up with a fully wo= rking rev file. -----Original Message----- From: Justin Georgeson [mailto:JGeorgeson@lgc.com]=20 Sent: Tuesday, August 03, 2010 1:37 PM To: Daniel Shahaf Cc: users@subversion.apache.org Subject: RE: corrupt revision, "Reading one svndiff window read beyond the = end of the representation" The new test repo up to r39244 was created and the merge was successfully c= ommitted. Checking the rev file in that new repo it looks ok. But when I pu= t the new rev file into an existing repo it is still corrupt, although for = different reasons now. I tried fsfsverify.py on this new rev file just in c= ase, same error. [svnadmin@hourdcm1 /tmp]$ svnadmin verify -r 39245 /u1/repos/prowess svnadmin: Corrupt node-revision 'g-17515.0-38388.r38555/6646' svnadmin: Found malformed header in revision file That string comes from this entry K 19 SmartInputTool.java V 32 file g-17515.0-38388.r38555/6646 Which is the entry just prior to the entry for the file that was modified i= n this merge. If I change the entry to match that of the original rev file = then (change the trailing /6646 to /6649) then the verify fails with a chec= ksum mismatch. Interestingly I don't see the 'actual' checksum anywhere in = the file, but I do see the expected. [svnadmin@hourdcm1 /tmp]$ svnadmin verify -r 39245 /u1/repos/prowess svnadmin: Checksum mismatch while reading representation: expected: 2acda48d7b91e8f07aff6270fdcb9e7b actual: 7d22c19004b23609f3a460fb9adbed96 [svnadmin@hourdcm1 /tmp]$ grep 2acda48d7b91e8f07aff6270fdcb9e7b /u1/repos/p= rowess/db/revs/39/39245 text: 39245 605 1191 1191 2acda48d7b91e8f07aff6270fdcb9e7b [svnadmin@hourdcm1 /tmp]$ grep 7d22c19004b23609f3a460fb9adbed96 /u1/repos/p= rowess/db/revs/39/39245 [svnadmin@hourdcm1 /tmp]$ =20 -----Original Message----- From: Justin Georgeson=20 Sent: Tuesday, August 03, 2010 10:03 AM To: 'Daniel Shahaf' Cc: users@subversion.apache.org Subject: RE: corrupt revision, "Reading one svndiff window read beyond the = end of the representation" Regarding reproducibility, that's what I was going for with #3. I found ano= ther thread, http://svn.haxx.se/users/archive-2009-06/0723.shtml, concludin= g this error is due to fsfsverify not being current with the latest format,= so I'll give the svndump to new repo and redo revision in new repo a try. -----Original Message----- From: Daniel Shahaf [mailto:d.s@daniel.shahaf.name]=20 Sent: Tuesday, August 03, 2010 9:30 AM To: Justin Georgeson Cc: users@subversion.apache.org Subject: Re: corrupt revision, "Reading one svndiff window read beyond the = end of the representation" Justin Georgeson wrote on Mon, Aug 02, 2010 at 17:39:49 -0500: > I have a repo with >39k revisions. Last week, r39245 was committed, a mer= ge of a single file from trunk to branch. It is the HEAD revision of that f= ile on that branch. Turns out this revision is corrupt >=20 > [svnadmin@hourdcm3 ~]$ svnadmin verify -r 39245 /repos/prowess > svnadmin: Reading one svndiff window read beyond the end of the represent= ation >=20 Is this reproducible? i.e., if you re-commit r39245 (on top of, say, an svnsync/backup repository at r39244), does it become corrupted again? > I've searched from r30000 to HEAD in this repo and that's the only rev th= at fails the verify. All our backup copies have the same issue too. I'm won= dering what our options for recovery are. Some suggestions we have come up = with internally are: >=20 > 1. Developer still has sandbox which reports the parent folder as updated= , so have him 'svn cat' the previous version and commit that, then re-commi= t the changes from the corrupt revision > 2. 'svn rm' the file from the server and re-add it (losing ancestry) > 3. Some combination of svndump up to that revision, import to new repo, r= edo that merge in new repo, overwrite the revision file with new one > 4. delete revision file (seems like bad idea) > 5. svn dump up to corrupt revision and everything after bad revision, mer= ge dumps, create new repo, redo merge >=20 Don't do #4. #5 sounds reasonable. You have to restitch history in some way now. > Is there something else we missed? Which of these seems like the safest/e= asiest? >=20 > ---------------------------------------------------------------------- > This e-mail, including any attached files, may contain confidential and p= rivileged information for the sole use of the intended recipient. Any revi= ew, use, distribution, or disclosure by others is strictly prohibited. If = you are not the intended recipient (or authorized to receive information fo= r the intended recipient), please contact the sender by reply e-mail and de= lete all copies of this message.