So why doesn’t it work with socketpair()? Is socketpair()? broken on Cygwin?

…
In short:
Compile rsync from source and use pipes instead of socketpair.

# To do this:
cd /usr/src/rsync-3.0.6/
./prepare-source
./configure

# Now undefine HAVE_SOCKETPAIR in config.h
# Search for /HAVE_SOCKETPAIR
# Comment out
# #define HAVE_SOCKETPAIR 1
# //#define HAVE_SOCKETPAIR 1
vi config.h
// #define HAVE_SOCKETPAIR 1

make
make install

# Instead of overwriting the original executable
# at /bin/rsync use the compiled executable
# (/usr/local/bin/rsync.exe) in your backup scripts.
# This way, even if /bin/rsync gets overwritten
# by cygwin setup.exe, we are still using the good
# rsync version compiled from source.

See
cygwin {at} cygwin(.)com/msg82514.html" rel="nofollow">http://www.mail-archive.com/cygwin {at} cygwin(.)com/msg82514.html

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 affected by the above change (primarily) is
util.c in function: fd_pair():

#ifdef HAVE_SOCKETPAIR
ret = socketpair(AF_UNIX, SOCK_STREAM, 0, fd);
#else
ret = pipe(fd);
#endif

While use of socketpair() may be a better method, use of
pipe() does work.
…

Since this is the top hit on Google for “rsync hangs windows”, I thought I’d outline how the paranoid amongst us can still use SSH:

1. On the server, set “hosts allow = 127.0.0.1″ in rsyncd.conf. This will only allow local connections to the rsync server
2. On the client, SSH in to the server, forwarding local port 873 to localhost:873. In PuTTY, this is configured through Connection->SSH->Tunnels in the PuTTY configuration.
3. On the client, change rsync://server/whatever to rsync://localhost/whatever and run rsync in the normal way

Basically, instead of getting the rsync client to talk to a remote rsync server, this uses a feature of SSH that fools the client and server into thinking they’re on the same computer. I have no idea why this should be any better, but it works fine for me.

- Andrew Sayers