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

Re: write through proxy configuration on windows / apache / svn causing checksum mismatch errors

From: Russell Van Tassell <russell+svn-users_at_loosenut.com>
Date: Fri, 19 Jun 2009 18:56:02 -0700

On Thu, Apr 02, 2009 at 12:01:02PM -0400, Seymen Ertas wrote:
> Hi all,
>
> I am having an interesting issue with a master slave configuration of SVN.
>
> Some files (seems to be larger ones) cause checksum mismatch error as follows:
>
> Checksum mismatch, file '/XXXX XX.png':\n
> expected: d37443091695c3f64ebc6f2d4d7a421c\n
> actual: 4a28f19a9c8f765f5df26c730bdaeca0\n
>
> during a commit operation. This file does not exist on the server and
> it is the initial commit.

We've been battling this issue here and there for a little bit now, as
well, and I think we may have found the smoking gun earlier this week;
now we're attempting to fix it in our server(s). File size is *not* an
issue, however, and we've been able to reproduce the problem with a file
in the 2k neighborhood.

For a quick reference, one of our engineers sent a message to the SVN
dev mailing list to confirm and/or see if there's an easy/suggested fix.

   http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2363710

More of the gory details, however, follows.

In the case of a mirrored system, there appears to be some level of
content filtering done on the message body when it's sent through the
proxy and up to the master. To be more specific, seems there's a
case-insensitive replacement of part of the respository path done to
the message payload (eg. /SVN becomes /svn).

After chasing around for a few "off-by-one" and similar situations, we
reassembled the "actual" file transmitted to the master and correctly
verified the "actual" checksum. A quick diff of that file against the
original file showed a simple three-character difference (the smoking
gun). That was "SVN" versus "svn" (the leading path of our repository).

> I do have a file available which reproduces the issue every time as
> well ethereal (now called wireshark) dumps of the transmission.
>
> Just wondering anyone out there has some thoughts on the subject or
> things to try out ?

You can see if you can use that snoop to reassemble the file, and then
diff i to see if your issue corresponds? Or perhaps you can try to
construct a smaller file that also demonstrates the issue and go from
there?

Here's my "sanitized" demonstration of the issue.

-- begin
~/svn/sandbox> svn commit -m "Adding problematic SVN Checksum file"
Subversion repository Password for 'russell':
Adding sandbox
Adding sandbox/viewvc.cgi
Transmitting file data .svn: Commit failed (details follow):
svn: Checksum mismatch, file '/sandbox/viewvc.cgi':
   expected: f2e005d5c37fd9eacfe2cc903b9f3a09
     actual: 3dee21801aa7c412b9e973ac1b2fc7dd

~/svn/sandbox> openssl md5 viewvc*
MD5(viewvc-case.cgi)= 3dee21801aa7c412b9e973ac1b2fc7dd
MD5(viewvc.cgi)= f2e005d5c37fd9eacfe2cc903b9f3a09
~/svn/foo/trunk/sandbox> diff viewvc.cgi viewvc-case.cgi
14c14
< # viewvc: View CVS/SVN repositories via a web browser

---
> # viewvc: View CVS/svn repositories via a web browser
-- end
Hope that helps!
Russell
Received on 2009-06-20 04:07:01 CEST

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.