Dear reader(s),
First, I'll state the goal: Synchronizing data using rsync on CygWin
(win2k3 servers) via a data 'pull' and ssh
On a remote system, data is exported to files, and rsync is used to
synchronize the data from a remote server to our local server (so a
data 'pull').
When synchronizing the data (rsync -e "ssh -p 1500" --progress -v
--timeout=600 --compress --times user@localserver:/folder/*.*
/localfolder/.), after some files being updated, rsync stops
responding and a timeout occurs. On the remote server, rsync remains
running as a process as if it 'hangs'.
Note that the connection via port 1500 works fine, directory contents
can be retrieved via rsync without problems.
When using the '--whole-file' option, no problems occur, data is
transfered perfectly, however, this is ignoring one of the key
features of rsync.
I've noticed some mails with regard to this issue in this mailing list
on August 14th 2006 (
http://cygwin.com/ml/cygwin/2006-08/msg00487.html ). A follow-up,
mentions the following:
--- begin of copy from follow up message ---
Yes its a known issue for the exact situation you explain. Pulling
files from a hosting using ssh+rsync under CYGWIN.
My current understanding of the situation is with the non-blocking
implementation of pipes under CYGWIN does not return EAGAIN even the
pipe buffer is full and starts to block.
This causes rsync to become blocked on a write call to send data to
ssh, and ssh becomes blocked also on a write call sending data to
rsync. This causes a deadlock.
Since rsync can work in blocking and non-blocking mode its really SSH
that end that has the problem.
--- end of copy from follow up message ---
Is it possible that I'm suffering from this known issue?
Is there a patch available?
I'm using OpenSSH 4.5p1-1 and rsync 2.6.6. I have even compiled rsync
2.6.9, but this has not resolved the issue.
In order to rule out a server issue, I was able to reproduce the
problem on another server as well (using a fresh install of CygWin).