error in rsync protocol data stream (code 12) at token.c(288)

[Stuart Anderson]

According to sba:
> According to Dave Dykstra:
> > On Thu, Jan 31, 2002 at 03:26:16PM -0800, Stuart Anderson wrote:
> > > I am getting the following error when mirroring part of the RedHat
> > > distribution tree over a slow connection (~T1 speed). When running
> > > over a faster network (100BaseT) the problem does not appear. Note,
> > > the problem file a large 600MB ISO image, whereas other small files
> > > appear to be fine.
> > > 
> > > rsync: open connection using /path/ssh remote.host /path/rsync --server -vlHogDtprRz --timeout=600 --delete --force . / 
> > > rsync: building file list...
> > > rsync: 90108 files to consider.
> > > export/mirror/linux/redhat/7.1/en/iso/i386/
> > > /export/mirror/linux/redhat/7.1/en/iso/i386/seawolf-i386-powertools.iso
> > > deflate on token returned 0 (16384 bytes left)
> > > rsync error: error in rsync protocol data stream (code 12) at token.c(288)
> > > rsync finished
> > > 
> > > 
> > > The file has in fact been mirrored correctly (md5sum is identical),
> > > however, the file is left with today's date rather synchronizing the
> > > file times as specified.
> > > 
> > > A repeat of the rsync command with the file already on the destination
> > > machines results in the same error.
> > > 
> > > 
> > > This is running between two Sun servers running Solaris 8 and using:
> > > 
> > > rsync  version 2.5.2  protocol version 26
> > > Copyright (C) 1996-2002 by Andrew Tridgell and others
> > > <http://rsync.samba.org/>
> > > Capabilities: 64-bit files, socketpairs, hard links, symlinks, batchfiles, no IPv6,
> > >               64-bit system inums, 64-bit internal inums
> > 
> > 
> > 
> > That's a different symptom than what we've seen before, but have you
> > applied the following patch that I posted on Tuesday?  Rsync 2.5.2 is badly
> > broken without it.
> > 
> > - Dave Dykstra
> > 
> > 
> > --- match.c.O	Tue Jan 29 15:31:37 2002
> > +++ match.c	Tue Jan 29 15:31:54 2002
> > @@ -246,7 +246,7 @@
> >  		   match. The 3 reads are caused by the
> >  		   running match, the checksum update and the
> >  		   literal send. */
> > -		if (offset-last_match >= CHUNK_SIZE+s->n && 
> > +		if (offset-last_match >= CHUNK_SIZE+(int)s->n && 
> >  		    (end-offset > CHUNK_SIZE)) {
> >  			matched(f,s,buf,offset - s->n, -2);
> >  		}
> 
> 
> No I did not apply the patch, but I verified the same problem with
> rsync-2.4.8, is that sufficient?
> 
> I also determined that my comment above about working/not-working on
> fast/slow network was misleading. The important discriminant is whether
> compression was turned on or not: works without out it, fails with it
> (my driver script was automatically selecting compression for slow
> networks).
> 
> I also found on deja-news reports that this is a known and fixed problem
> with zlib-1.1.2. Any chance of rsync upgrading to zlib-1.1.3?
> 

I have verified that the (int) typecast fix to match.c does not solve
this problem.

I have also determined that a good way to reproduce this problem is
to touch (change the timestamp) on some large iso files and then
attempt to re-rsync them with compression turned on, i.e., no need
to re-push the actual file over the network.


-- 
Stuart Anderson  sba at srl.caltech.edu  http://www.srl.caltech.edu/personnel/sba