Sorry to bring back this old thread back. Is there anyone that can explain a fix for this problem. I've only been using rsync/cygwin/on ssh for about 3 weeks, so please explain in dummy terms.

It's the exact same problem mentioned here:
----- Original Message ----- From: "René Berber"
Steven Hartland wrote:
Just to back this up, we cant get basic rsync to run reliably
using cygwin either. The command being tested is run from a
FreeBSD box with the source being a cygwin box using cygwin
rsync -av cygwin1:/testdir/ /testdir/

The result is it will randomly hang on a file, no output / error
returned just stops.

tcsh                    6.14.00-5          OK

While testing is csh involved?

Your description above is very close to a problem with cvs reported and solved recently by Jay Abel. In short, tcsh at the receiving end is changing \r\n to \n inside binary files, so the receiving process waits for the expected bytes
but it receives less.

tcsh is the default shell on FreeBSD which is the "recieving"
end in this test yes but I'm a little confused how the shell
could effect the results of rsync? FreeBSD to FreeBSD for FreeBSD
to Windows SFU doesnt have this issue so something specific to
tcsh on cygwin?

An example of this failure is:
rsync -av --progress cygwin1:/testdir/ /testdir/
receiving file list ...
1705 files to consider
created directory testdir
          0   0%    0.00kB/s    0:00:00
***Hung here***
^CKilled by signal 2.0.00kB/s    0:00:00
rsync error: received SIGINT, SIGTERM, or SIGHUP (code 20) at rsync.c(242) [receiver]
rsync error: unexplained error (code 255) at rsync.c(242) [generator]

Brett Serkez wrote:
After running into the hang trying to use rsync over ssh on Cygwin,
reported on this mailing list, but with no resolution other than use of
daemon mode, I tracked down the problem.  I have rsync working over ssh
on Cygwin.

The hang is occuring when rsync is attempting to exchange protocol
version numbers, it writes its version and then hangs waiting endlessly
for a reply.  The ssh process is detached, and apparently not diretly
connected to rsync, as it is an orphan, owned by process 1.  The ssh
process never even gets as far as attempting network access and rsync
never does anything of value.

Not defining HAVE_SOCKETPAIR in the make configuration is enough to use
pipe() vs. socketpair(), which is enough for rsync to run using ssh,
just as it does on UNIX.  While I've not done extensive testing, I've
used it enough to believe it is working as designed/intended.

The source file that is effected by the above change (primarily) is
util.c in function: fd_pair():

        ret = socketpair(AF_UNIX, SOCK_STREAM, 0, fd);
        ret = pipe(fd);

While use of socketpair() may be a better method, use of pipe() does
work and I'd request that the rsync package maintainer please rebuild
the package with this build option change and reissue the package so all
can benefit.  Perhaps socketpair() can be used with a future release of

Thank you,

Brett C. Serkez, Techie

Unsubscribe info:
Problem reports:

Reply via email to