Ok I have looked through the mailing list archives...don't find any
answers; everyone running into this problem seems to be using the
daemon.
I am transferring several hundred megs from a Solaris 2.5.1 machine to a
Linux-2.2/glibc-2.1 machine. SSH is being used as the transport; it
uses pipe()s instead of socketpair()s.
If I set blocking IO on the remote (I am pushing the files instead of
pulling...is necessary in this case) with the 2.4.4 long option, rsync
will transfer lots of files and then hang at an arbitrary point.
If I do not set blocking IO on the remote, then rsync will transfer lots
of files and then abort with "unexpected EOF in read_timeout"
If I set an exorbitant IO timeout, there is no change in behavior.
Am I right in thinking that there is no way to use rsync-2.4.4 with ssh
v1 as the transport, without either
- building SSH to use socketpair() instead of pipe()
- hacking on rsync's io.c somewhere
This is amazing that release after release, it fails to work with one or
the other of rsh or ssh. Perhaps there should be a compile-time option
to build for ssh use only, and another to build for rsh use only. If
anyone has used these in combination successfully, please tell me I am
crazy. This is driving me nuts.
To Dave Dykstra: I read in one of your posts that you use 2.3.2 (IIRC)
at your shop because of these constant problems. Is there any caveats I
would have to be aware of when using this older version (such as, in
scenario XYZ, all your files will be hosed, or permissions will be
propagated incorrectly)? If 2.3.2 actually works I'll probably just
revert at all our sites.
