subversion-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Myria <myriac...@gmail.com>
Subject Re: SHA-1 collision in repository?
Date Mon, 26 Feb 2018 21:41:05 GMT
-bash-4.1$ sqlite3 rep-cache.db "select * from rep_cache where
hash='db11617ef1454332336e00abc311d44bc698f3b3'"
db11617ef1454332336e00abc311d44bc698f3b3|604440|34|134255|136680

The line from the grep -a command containing that hash is below.  They
all match.
text: 604440 34 134255 136680 c9f4fabc4d093612fece03c339401058
db11617ef1454332336e00abc311d44bc698f3b3 604439-cyqm/_13


In other news, unknown whether related to the current problem, my
attempt to clone the repository to my local computer is failing:

D:\>svnsync sync file:///d:/svnclone
Transmitting file data
.....................................................................................................................................................svnsync:
E160000: SHA1 of reps '227170 153 193 57465
bb52be764a04d511ebb06e1889910dcf
e6291ab119036eb783d0136afccdb3b445867364 227184-4vap/_4o' and '-1 0
193 57465 bb52be764a04d511ebb06e1889910dcf
e6291ab119036eb783d0136afccdb3b445867364 227184-4vap/_4o' matches
(e6291ab119036eb783d0136afccdb3b445867364) but contents differ
svnsync: E160004: Filesystem is corrupt
svnsync: E200014: Checksum mismatch while reading representation:
   expected:  bb52be764a04d511ebb06e1889910dcf
     actual:  80a10d37de91cadc604ba30e379651b3

This is odd, because revision 227185 (the revision it's trying to
commit) verifies fine on the originating server:

-bash-4.1$ sudo svnadmin verify -r227170 /srv/subversion/repositories/meow
* Verifying repository metadata ...
* Verifying metadata at revision 227170 ...
* Verified revision 227170.
-bash-4.1$ sudo svnadmin verify -r227185 /srv/subversion/repositories/meow
* Verifying repository metadata ...
* Verified revision 227185.

On Fri, Feb 23, 2018 at 5:42 PM, Philip Martin <philip@codematters.co.uk> wrote:
> Philip Martin <philip@codematters.co.uk> writes:
>
>> There are a couple of options:
>>
>>   A) disable rep-caching by editing fsfs.conf inside the repository
>>
>>   B) reset the mapping by deleting/renaming the file db/rep-cache.db
>>      inside the repository (but please rename rather than delete if you
>>      want to help us identify the corruption)
>>
>> Doing either of these should allow the commit to succeed.
>
> To verify the corruption start with the rep-cache:
>
>   sqlite3 db/rep-cache.db "select * from rep_cache where hash='db11617ef1454332336e00abc311d44bc698f3b3'"
>
> That should give you five numbers: the hash, the revision (604440), the
> offset, the size and the expanded size.
>
> Then examine the revision file for r604440.  It could be unpacked:
>
>   grep -a "^text: 604440.*/_" db/revs/604/604440
>
> or packed:
>
>   grep -a "^text: 604440.*/_" db/revs/604.pack/pack
>
> One of the lines from grep should contain the hash and that line should
> start:
>
>   text: 604440
>
> followed by three more numbers then hashes and other stuff.  The three
> numbers are the offset, size and expanded size and should match the
> values from the rep-cache but I suspect the rep-cache has the wrong
> offset.
>
> --
> Philip

Mime
View raw message