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 [EMAIL PROTECTED] http://www.srl.caltech.edu/personnel/sba
