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

Re: corrupt binary files

From: Eric Weidner <esw-lists_at_openlogic.com>
Date: 2005-05-24 19:45:16 CEST

Update:

I moved the repository to SuSE 9.3 x86_64 running svn 1.1.3 and the
problem does not occur yet.

Correction to below..., the commandline client is svn 1.1.3. Would a
1.1.3 client connecting to a 1.1.4 server cause issues?

Eric

On Mon, 2005-05-23 at 19:03 -0600, Eric Weidner wrote:
> Update:
>
> The problem seems to be with the DAV module rather than the actual
> check-in. I had checked in a whole directory of binaries and verified
> that they checked out fine. Then after adding 2 other directories, a
> checkout had an issue with a file that was previously ok in the 1st
> directory.
>
> Eric
>
> On Mon, 2005-05-23 at 18:45 -0600, Eric Weidner wrote:
> > Server:
> > Debian Sid
> > Subversion 1.1.4
> > Apache 2.0.53 with WebDAV subversion module 1.1.4
> >
> > Client:
> > SuSE 9.3 (x86_64)
> > Subversion 1.1.4 command line
> >
> >
> > ---------------------------------------------------------------
> >
> > I am having a problem where my binary files are becoming corrupt.
> >
> > Here's the situation...
> >
> > I started with a directory /trunk/project1/packages that contained
> > several binary files (.zip's, .tar.gz's mostly). Everything was working
> > fine.
> >
> > Then I decided that the directory was getting too large so I moved it up
> > to a top level project like so...
> >
> > svn move http://svn.myserver.com/svn/trunk/project1/packages
> > http://svn.myserver.com/svn/trunk/packages
> >
> >
> >
> > That seemed to work, but later I had problems with a fresh check out.
> >
> > Client error message:
> >
> > svn: REPORT request failed on '/svn/!svn/vcc/default'
> > svn: The REPORT request returned invalid XML in the response: XML parse
> > error at line 10938981: Extra content at the end of the document
> > . (/svn/!svn/vcc/default)
> >
> >
> > Apache server error message:
> >
> > Mon May 23 18:28:38 2005] [error] [client 192.168.10.91] Provider
> > encountered an error while streaming a REPORT response. [500, #0]
> > [Mon May 23 18:28:38 2005] [error] [client 192.168.10.91] A failure
> > occurred while driving the update report editor [500, #160004]
> > [Mon May 23 18:28:38 2005] [error] [client 192.168.10.91] Checksum
> > mismatch while reading representation:\n expected:
> > 09585df7d0ababd8bca38e117b1072f5\n actual:
> > b39cd4fc23d281e482cdb0070f8f16cb\n [500, #160004]
> >
> >
> > I have figured out that this is related to the binary file data being
> > corrupt. The server knows what the checksum should be, but it does not
> > get the correct file to pass along to the client.
> >
> > I then just removed the whole project and created it fresh from scratch
> > and add the binaries back in manually. Still have the same problem.
> >
> > Further investigation shows that it seems safe if I add and commit one
> > binary file at a time. If I do multiples, it increases the risk of bad
> > files in the repository.
> >
> > Any ideas on this problem? This is a very scary situation. I am not
> > comfortable that my data is safe.
> >
> > Thanks for any help,
> >
> > Eric
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> > For additional commands, e-mail: users-help@subversion.tigris.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Tue May 24 19:47:16 2005

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.