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

[Stuart Anderson]

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?


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