rsync - Jan 2005 - error in rsync protocol data stream (code 12) at io.c(692)

Hi Wayne, Jeff,

With the same version/build as the last report, I got this error now:

	...
	extra/state/all-packages.list
	     1458888 100%   46.83kB/s    0:00:30  (634, 0.0% of 201605)
	WARNING: fedora/1/en/i386/base/pkglist.dag.bz2 failed verification -- 
	update put into partial-dir (will try again).
	unexpected tag -111
	rsync error: error in rsync protocol data stream (code 12) at io.c(692)

Can this be caused by the delay-renames patch ?

Kind regards,
--   dag wieers,  dag@wieers.com,  http://dag.wieers.com/   --
[all I want is a warm bed and a kind word and unlimited power]

On Thu, 13 Jan 2005, Dag Wieers wrote:
> Hi Wayne, Jeff,
> 
> With the same version/build as the last report, I got this error now:
> 
> 	...
> 	extra/state/all-packages.list
> 	     1458888 100%   46.83kB/s    0:00:30  (634, 0.0% of 201605)
> 	WARNING: fedora/1/en/i386/base/pkglist.dag.bz2 failed verification -- 
> 	update put into partial-dir (will try again).
> 	unexpected tag -111
> 	rsync error: error in rsync protocol data stream (code 12) at io.c(692)
> 
> Can this be caused by the delay-renames patch ?
After this, got another one:

	source/perl-Net-XMPP-1.0-1.rf.src.rpm
	       99575 100%    1.28kB/s    0:00:51  (645, 99.6% of 200819)
	WARNING: extra/state/all-packages.list failed verification -- update put 
	into partial-dir (will try again).
	unexpected tag 60
	rsync error: error in rsync protocol data stream (code 12) at io.c(692)

--   dag wieers,  dag@wieers.com,  http://dag.wieers.com/   --
[all I want is a warm bed and a kind word and unlimited power]

On Thu, Jan 13, 2005 at 07:51:33PM +0100, Dag Wieers
wrote:
> 	unexpected tag -111
> 	rsync error: error in rsync protocol data stream (code 12) at io.c(692)
> 
> Can this be caused by the delay-renames patch ?
I don't think so.  An "unexpected tag" error indicates that
something
went wrong in the synchronization of the data being transferred over the
socket, which is pretty strange.  While looking into this, I did notice
a couple minor problems in the --partial-dir code in CVS (these aren't
in the 2.6.3 code as they were caused by new features getting added to
the codebase):

 - If --whole-file is in effect, the generator would ignore the presence
   of a basis file in the partial-dir, and the file would therefore not
   be removed by the receiver (because the receiver now depends on the
   generator to be told what the basis file is for the transfer).

 - If --whole-file is NOT in effect, the generator might use a partial-
   dir file for the basis but not be able to tell the receiver about it
   (since the "name pipe" might not have been requested).  This could
   result in a corrupted transfer if the basis file for the generator
   was the partial-dir file and the basis file for the receiver was the
   normal file.

I tested how the code handles the verification-failed redo phase, both
with and without the --delayed-rename patch, and I didn't get it to
fail.  I thereafter diagnosed and checked-in fixes for the two problems
above.  You'll probably want to check-out the latest CVS source to get
them (since --delayed-renames makes use of the --partial-dir logic).

..wayne..