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

[Seymen Ertas <ma...@seymen.com>]

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.

My configuration is as follows:

Apache 2.2.11
SVN 1.6.0 (1.5.6 encounters the same error)
OS: Windows XP master and slave (same behavior observed with Windows
2003 server)

I have been able to commit other large file (sizes around 13.5 mega
bytes) without a problem. Also interestingly enough if the file is
committed directly to the master repository this works without a hitch
as well.

When the issue is encountered the error.log on the master machine
shows (no errors are shown on slave):

"mod_dav_svn close_stream: error closing write stream  [500, #200014]"

Additional if i calculate MD5 using a code (just writing simple code
for MD5 computing) the result i obtain matches the result calculated
by the svn client ("expected" value).

I have read some articles regarding TCP Large Send options on the
network cards one of the configuration this was tried did have the
setting on the network card which we did try to disable but that did
not resolve the issue either.

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 ?

Thank you
-seymen

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=1520684

To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].

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

[Russell Van Tassell <ru...@loosenut.com>]

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