rsync - Oct 2007 - To inc_recurse or not to inc_recurse? [Re: 3.0.0pre2: bookend breakage (2 different errors)]

On 10/15/07, Erik Jan Tromp <betageek@sympatico.ca>
wrote:
> # The second error
> Invalid file index: -101 (-1 - 0) with iflags 0 [receiver]
> rsync error: protocol incompatibility (code 2) at rsync.c(273)
[receiver=3.0.0pre2]
> rsync: connection unexpectedly closed (21 bytes received so far)
[generator]
> rsync error: error in rsync protocol data stream (code 12) at io.c(596)
[generator=3.0.0pre2]
>
> # Sample commands, obfuscated to protect the guilty
> cp -alf $BACKUPPATH/fluorine/sunday/. $BACKUPPATH/fluorine/monday/
> rsync [...] --delete-after [...]
>   rsync://$BACKUPUSER@fluorine:$BACKUPPORT/$BACKUPMODULE/ \
>   $BACKUPPATH/fluorine/monday/ [...]
This is the same problem I ran into with --detect-renamed: the client
disables incremental recursion because of --delete-after but doesn't
send the option to the server, so the server has no idea that it is
supposed to disable incremental recursion.  The other options that can
disable incremental recursion (see compat.c) may cause the same crash.

I suppose server_options could be changed to send all of these options
unconditionally.  However, a more discreet and much more robust
solution would be for the client and server to negotiate whether to
incrementally recurse just after negotiating the protocol version.

Matt

On Mon, Oct 15, 2007 at 11:15:34PM -0400, Matt McCutchen
wrote:
> However, a more discreet and much more robust solution would be for
> the client and server to negotiate whether to incrementally recurse
> just after negotiating the protocol version.
Yeah, I agree that it is better for the client to explicitly tell the
server what is going on (and allows a batch file to indicate what is
happening too).  That way there is no confusion.  It also allows for
future expansion in certain situations -- e.g. I can imagine making a
future version of --prune-empty-dirs and/or --delay-updates compatible
with inc-recursion, and this will allow a more modern rsync to try to
tell a remote receiver to use that option and stay in inc_recurse mode,
and the receiver can say "no, I don't support that". 

The CVS version (and latest nightly) have this fixed.

..wayne..

On 10/16/07, Wayne Davison <wayned@samba.org>
wrote:
> Yeah, I agree that it is better for the client to explicitly tell the
> server what is going on (and allows a batch file to indicate what is
> happening too).
Now you could revert the unconditional sending of --detect-renamed in
detect-renamed.diff; the new detect-renamed.diff is attached.

Matt
-------------- next part --------------
A non-text attachment was scrubbed...
Name: detect-renamed.diff
Type: text/x-patch
Size: 21889 bytes
Desc: not available
Url :
http://lists.samba.org/archive/rsync/attachments/20071016/5da2bf85/detect-renamed.bin

On Mon, 15 Oct 2007 23:15:34 -0400
"Matt McCutchen" <hashproduct+rsync@gmail.com> wrote:
> On 10/15/07, Erik Jan Tromp <betageek@sympatico.ca> wrote:
> > # The second error
> > Invalid file index: -101 (-1 - 0) with iflags 0 [receiver]
> > rsync error: protocol incompatibility (code 2) at rsync.c(273)
[receiver=3.0.0pre2]
> > rsync: connection unexpectedly closed (21 bytes received so far)
[generator]
> > rsync error: error in rsync protocol data stream (code 12) at
io.c(596) [generator=3.0.0pre2]
> >
> > # Sample commands, obfuscated to protect the guilty
> > cp -alf $BACKUPPATH/fluorine/sunday/. $BACKUPPATH/fluorine/monday/
> > rsync [...] --delete-after [...]
> >   rsync://$BACKUPUSER@fluorine:$BACKUPPORT/$BACKUPMODULE/ \
> >   $BACKUPPATH/fluorine/monday/ [...]
For the record, I no longer get this error after updating from cvs (Wed Oct 17
10:28:30 UTC 2007).

Erik

-- 
"Failure is not an option. (It comes bundled with Windows.)"
"If at first you don't succeed, redefine success."