Please would you file this issue in the issue tracker so I can give
outsiders a reference to it?
- Julian
Philip Martin wrote:
> Philip Martin <philip_at_codematters.co.uk> writes:
>
>> svn cat http://svn.apache.org/repos/asf/subversion/trunk/INSTALL@1826165 > f1
>> (for i in `seq 0 8712`;do echo -n $i;done && echo -n 11111) > f1
>> svnadmin create repo
>> svnmucc -mm -U file://`pwd`/repo put f1 f
>> svnmucc -mm -U file://`pwd`/repo put f2 2
>> svnmucc -mm -U file://`pwd`/repo put f1 f
>
> Oops again! All three commits should be to destination 'f'.
>
> svn cat http://svn.apache.org/repos/asf/subversion/trunk/INSTALL@1826165 > f1
> (for i in `seq 0 8712`;do echo -n $i;done && echo -n 11111) > f2
> svnadmin create repo
> svnmucc -mm -U file://`pwd`/repo put f1 f
> svnmucc -mm -U file://`pwd`/repo put f2 f
> svnmucc -mm -U file://`pwd`/repo put f1 f
>
> The cause of the bug, as identified by Melissa, is that the wrong
> expanded size if computed -- it gets set to the size of the delta in the
> protorev file. The svn_stream_t that is producing the fulltext works in
> 16K chunks, so the total amout of fulltext goes up in steps: 16K, 32K,
> 48K, etc. If one of those steps happens to match the erroneous expanded
> size the stream treats that as the end of the fulltext. The stream then
> finalizes the MD5 checksum for the partial fulltext and the MD5 checksum
> failure occurs.
>
> For most commits the protorev delta is not a multiple of 16K and so the
> erroneous expanded size does not match any of the fulltext steps.
> Eventually the stream reaches EOF and gets a short read less than 16K.
> The function svn_stream_contents_same2 recognises the short read as EOF
> and ends the comparison between the two streams, however the stream
> itself has not finalized the checksum because of the length mismatch.
> This means we did not verify the MD5 checksum for the protorev fulltext
> but we did verify that the protorev fulltext matches the fulltext in the
> repository.
>
Received on 2018-03-08 11:19:42 CET