rsync - Aug 2012 - rsync 3.0.9 incompatible with self? (proto incompat on local->local)

Familiar?  protocol error on a local file copy?
How can I  have a proto incompat when it it is talking to itself?...

This was on the ERROUT...

rsync: writefd_unbuffered failed to write 4 bytes to socket [sender]: 
Broken pipe (32)
File-list index 531530 not in 531937 - 533437 (finish_hard_link) [generator]
rsync error: protocol incompatibility (code 2) at rsync.c(652) 
[generator=3.0.9]
rsync: connection unexpectedly closed (54286 bytes received so far) [sender]
rsync error: error in rsync protocol data stream (code 12) at io.c(605) 
[sender=3.0.9]



args used (approx, as they were passed in perl)...

--archive --8-bit-output --human-readable
                --acls --xattrs --hard-links
                --whole-file --one-file-system
            --compare-dest=/home/.
          --exclude={**/.recycle/**,bhome/la**,bhome/athen/**,
                             bhome/root**,bhome/mar** 
CPAN-ishtar-build-cache/**}
            /home/snapdir/old_snapdir/.  /home.diff/

This list seems awfully quiet...

This bug is caused by the incremental recursion added in 3.0.

That's the incompatibility -- incremental recursion is incompatible with
keeping the Hard links...

...

I didn't know hard links were so difficult for rsync...now I know why...
they don't pre-read the tree anymore...so there's no way they can
really keep track of what files need to be hard-linked -- thus
the hardlink generator fails because incremental-recursion is incompatible
with doing this... How LAME!... if that's the case, then -H should
auto-disable incremental recursion....
(which is what I did... I reran rsync with a different dataset and got another
failure like below, then I tried it with another dataset (daily diffs I can
only keep so long)... and it ran to completion.

Well...at least I know how to work around it...but until they get
incremental recursion fixed, it should probably be auto-disabled
for -H usage.

My storage requirements would seriously go up with hard links ignored.

(especially since I run deduplication on my files now and then that
links duplicates together!)....



Linda Walsh wrote:
> Familiar?  protocol error on a local file copy?
> How can I  have a proto incompat when it it is talking to itself?...
> 
> This was on the ERROUT...
> 
> rsync: writefd_unbuffered failed to write 4 bytes to socket [sender]: 
> Broken pipe (32)
> File-list index 531530 not in 531937 - 533437 (finish_hard_link) 
> [generator]
> rsync error: protocol incompatibility (code 2) at rsync.c(652) 
> [generator=3.0.9]
> rsync: connection unexpectedly closed (54286 bytes received so far) 
> [sender]
> rsync error: error in rsync protocol data stream (code 12) at io.c(605) 
> [sender=3.0.9]
> 
> 
> 
> args used (approx, as they were passed in perl)...
> 
> --archive --8-bit-output --human-readable
>                --acls --xattrs --hard-links
>                --whole-file --one-file-system
>            --compare-dest=/home/.
>          --exclude={**/.recycle/**,bhome/la**,bhome/athen/**,
>                             bhome/root**,bhome/mar** 
> CPAN-ishtar-build-cache/**}
>            /home/snapdir/old_snapdir/.  /home.diff/

On Sun, Aug 5, 2012 at 1:50 AM, Linda Walsh <rsync at tlinx.org> wrote:
> How can I  have a proto incompat when it it is talking to itself?...
>
You cited a hard-link bug in the incremental recursion algorithm.  You can
work around it by specifying --no-inc-recursive (--no-i-r).  If you have a
reproducible test case, I'd like to see it (if possible) to do some
debugging.

..wayne..
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.samba.org/pipermail/rsync/attachments/20120812/4c9e3422/attachment.html>