On Mon, 15 Oct 2007 23:15:34 -0400
Matt McCutchen [EMAIL PROTECTED] wrote:
On 10/15/07, Erik Jan Tromp [EMAIL PROTECTED] wrote:
# The second error
Invalid file index: -101 (-1 - 0) with iflags 0 [receiver]
rsync error: protocol incompatibility (code 2) at rsync.c(273)
On Tue, Oct 16, 2007 at 12:30:34AM -0400, Matt McCutchen wrote:
In this situation, automatically disabling incremental recursion would
be better than exiting with an error that really isn't the user's
fault.
Yeah. I hadn't wanted to add an extra round-trip delay that would be
required by a
On 10/15/07, Erik Jan Tromp [EMAIL PROTECTED] 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]
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
On 10/16/07, Wayne Davison [EMAIL PROTECTED] wrote:
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
On 10/16/07, Wayne Davison [EMAIL PROTECTED] 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
On 10/16/07, Matt McCutchen [EMAIL PROTECTED] wrote:
(That's why I said negotiate.)
One more thing I want to point out in case you haven't already thought
of it. Once two-way negotiation is in place, each side should refuse
incremental recursion only if it can't fulfill its *own* duties under
