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

[Matt McCutchen]

On 10/15/07, Erik Jan Tromp <betageek at 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