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

Dave Dykstra dwd at
Sat Feb 2 07:18:06 EST 2002

On Fri, Feb 01, 2002 at 09:09:18AM -0800, Stuart Anderson wrote:
> According to sba:

> > No I did not apply the patch, but I verified the same problem with
> > rsync-2.4.8, is that sufficient?

No, because rsync-2.4.8 include the same security patch that went into
2.5.2 last weekend.  If you could try 2.4.6 or 2.5.1 that would tell us if
it was some other problem introduced last weekend or not.

> 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.

Can you post a publicly-available URL for one that shows the symptom?

On Fri, Feb 01, 2002 at 11:48:19AM -0800, Stuart Anderson wrote:
> According to Albert Chin:
> > On Fri, Feb 01, 2002 at 08:51:17AM -0800, Stuart Anderson wrote:
> > > 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?
> >
> > Jos Backus posted a patch to do this a few days ago. Try applying his
> > patch and reporting back to the list if it solves your problem.
> >

Be careful with that, because rsync's zlib is modified from the standard.
Has somebody verified that the modification is not removed with the upgrade?

> Unfortunately, this does not solve my problem, i.e., the following fix
> in zlib-1.1.3 is not the one that rsync is triggering:
> - fix "an inflate input buffer bug that shows up on rare but persistent
>   occasions" (Mark)

I wonder if it's worth upgrading if nobody has experienced the problem in

- Dave Dykstra

More information about the rsync mailing list