You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Brendon Abbott <ba...@evertz.com> on 2015/01/29 12:43:23 UTC
Random Checksum mismatch on fresh checkout affecting single machine
Hi
I am part of a development team of approximately 30 people, all but a couple using Windows 7 64it clients. One of our users is experiencing random checksum errors when performing a fresh, clean checkout. The problem is random in that it is a different file every time we perform the test. Below is an example of the error. This case happens to show an XSL file, but it is any kind of file that goes wrong. This does not go wrong for any other user. We have tried to narrow it down to a directory, or repository. It appears that it fails all the time for one repository, yet using a different repository on the same server, a clean checkout worked twice in succession. I don't know whether this is just luck though.
I am presuming that the data received for the contents of the file is being validated against some metadata data for the file. We have tested using an externally attached hard drive to check the disk is not the problem - same outcome. Therefore I am presuming that the data is somehow becoming corrupt or going missing.
Is the client code check summing the disk contents, or the data as it comes from the TCP socket?
Please can somebody offer assistance as to how I can further look into this problem, or what the likely problem may be and why this would only affect a single machine.
Setup with problem:
Client: Win 7 64bit, svn 1.8.11 accessing via http
Server: Linux, openSuSE 13.1, subversion 1.8.11, apache 2.4.6. openSuSE provided binary RPMs. Tortoise, Subclipse and svn command line tool all present the same problem.
svn: Checksum mismatch for 'W:\000\pharosutilWIP\resource\xsl\pxf_templates-v1_9.xsl':
expected: a2bd8789226ed755298bd1c8d7e17535
actual: 34763dcfee82b6cbc18d63589d15e109
Many Thanks
Brendon
This e-mail and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this e-mail in error please notify the sender (as shown above). Kindly do not reproduce, print or forward any material received in error, please delete it immediately. Evertz UK Limited (Company No. 3458137) is incorporated in England and Wales and has its registered office at 100 Berkshire Place, Wharfedale Road, Winnersh, Wokingham, Berkshire, United Kingdom, RG41 5RD. Pharos Communications Pte Limited (Company No. 200817005N) is incorporated in Singapore and has its registered office at One Marina Boulevard, #28-00. Singapore 018989.
RE: Random Checksum mismatch on fresh checkout affecting single
machine
Posted by Brendon Abbott <ba...@evertz.com>.
Thanks for the response Ben.
I noticed the DEFLATE output filter being used in the subversion <Location>. I removed this on the off-chance it was causing issues. This had no effect. Unfortunately, because I am not at the same location as the problem client, it is only affecting a single client machine on this version, and the investigation time is taking resource from main development, the user has rolled their subversion client back to version 1.7
Thanks again
Brendon Abbott
________________________________________
From: Ben Reser [ben@reser.org]
Sent: 29 January 2015 18:43
To: Brendon Abbott; users@subversion.apache.org
Subject: Re: Random Checksum mismatch on fresh checkout affecting single machine
On 1/29/15 4:40 AM, Brendon Abbott wrote:
> Since writing this original email, I have found that the difference between the
> working instance and the non-working instance is not the repository, but the
> client. 1.6.17 works fine, whilst 1.8.11 does not.
This issue sounds suspiciously like what's described here to me (note the
second warning box):
http://subversion.apache.org/docs/release-notes/1.8.html#mod_dav_svn-fsmap
I'd check to see if your server has been misconfigured to modify the file
contents being sent to the client.
The reason you're seeing a difference in behavior with older clients is likely
because the default of using skelta style updates is now the default. When an
update happens via bulk update mode the file content is included in the report
and the filter that is triggering with a direct request of the content does not
get triggered.
The behavior change here is covered in this bit of the release notes as well:
http://subversion.apache.org/docs/release-notes/1.8.html#serf-skelta-default
This e-mail and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this e-mail in error please notify the sender (as shown above). Kindly do not reproduce, print or forward any material received in error, please delete it immediately. Evertz UK Limited (Company No. 3458137) is incorporated in England and Wales and has its registered office at 100 Berkshire Place, Wharfedale Road, Winnersh, Wokingham, Berkshire, United Kingdom, RG41 5RD. Pharos Communications Pte Limited (Company No. 200817005N) is incorporated in Singapore and has its registered office at One Marina Boulevard, #28-00. Singapore 018989.
Re: Random Checksum mismatch on fresh checkout affecting single machine
Posted by Ben Reser <be...@reser.org>.
On 1/29/15 4:40 AM, Brendon Abbott wrote:
> Since writing this original email, I have found that the difference between the
> working instance and the non-working instance is not the repository, but the
> client. 1.6.17 works fine, whilst 1.8.11 does not.
This issue sounds suspiciously like what's described here to me (note the
second warning box):
http://subversion.apache.org/docs/release-notes/1.8.html#mod_dav_svn-fsmap
I'd check to see if your server has been misconfigured to modify the file
contents being sent to the client.
The reason you're seeing a difference in behavior with older clients is likely
because the default of using skelta style updates is now the default. When an
update happens via bulk update mode the file content is included in the report
and the filter that is triggering with a direct request of the content does not
get triggered.
The behavior change here is covered in this bit of the release notes as well:
http://subversion.apache.org/docs/release-notes/1.8.html#serf-skelta-default
RE: Random Checksum mismatch on fresh checkout affecting single
machine
Posted by Brendon Abbott <ba...@evertz.com>.
Since writing this original email, I have found that the difference between the working instance and the non-working instance is not the repository, but the client. 1.6.17 works fine, whilst 1.8.11 does not.
So I am currently concentrating my efforts on the changes between these releases.
Brendon
From: Brendon Abbott [mailto:babbott@evertz.com]
Sent: 29 January 2015 11:43
To: users@subversion.apache.org
Subject: Random Checksum mismatch on fresh checkout affecting single machine
Hi
I am part of a development team of approximately 30 people, all but a couple using Windows 7 64it clients. One of our users is experiencing random checksum errors when performing a fresh, clean checkout. The problem is random in that it is a different file every time we perform the test. Below is an example of the error. This case happens to show an XSL file, but it is any kind of file that goes wrong. This does not go wrong for any other user. We have tried to narrow it down to a directory, or repository. It appears that it fails all the time for one repository, yet using a different repository on the same server, a clean checkout worked twice in succession. I don't know whether this is just luck though.
I am presuming that the data received for the contents of the file is being validated against some metadata data for the file. We have tested using an externally attached hard drive to check the disk is not the problem - same outcome. Therefore I am presuming that the data is somehow becoming corrupt or going missing.
Is the client code check summing the disk contents, or the data as it comes from the TCP socket?
Please can somebody offer assistance as to how I can further look into this problem, or what the likely problem may be and why this would only affect a single machine.
Setup with problem:
Client: Win 7 64bit, svn 1.8.11 accessing via http
Server: Linux, openSuSE 13.1, subversion 1.8.11, apache 2.4.6. openSuSE provided binary RPMs. Tortoise, Subclipse and svn command line tool all present the same problem.
svn: Checksum mismatch for 'W:\000\pharosutilWIP\resource\xsl\pxf_templates-v1_9.xsl':
expected: a2bd8789226ed755298bd1c8d7e17535
actual: 34763dcfee82b6cbc18d63589d15e109
Many Thanks
Brendon
This e-mail and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this e-mail in error please notify the sender (as shown above). Kindly do not reproduce, print or forward any material received in error, please delete it immediately. Evertz UK Limited (Company No. 3458137) is incorporated in England and Wales and has its registered office at 100 Berkshire Place, Wharfedale Road, Winnersh, Wokingham, Berkshire, United Kingdom, RG41 5RD. Pharos Communications Pte Limited (Company No. 200817005N) is incorporated in Singapore and has its registered office at One Marina Boulevard, #28-00. Singapore 018989.
This e-mail and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this e-mail in error please notify the sender (as shown above). Kindly do not reproduce, print or forward any material received in error, please delete it immediately. Evertz UK Limited (Company No. 3458137) is incorporated in England and Wales and has its registered office at 100 Berkshire Place, Wharfedale Road, Winnersh, Wokingham, Berkshire, United Kingdom, RG41 5RD. Pharos Communications Pte Limited (Company No. 200817005N) is incorporated in Singapore and has its registered office at One Marina Boulevard, #28-00. Singapore 018989.