> If there is something I can do in order to narrow down the problem, > please let me know. This issue has already been discussed on the rsync > list (https://bugzilla.samba.org/show_bug.cgi?id=2957) and Wayne from > the rsync project was quite sure about what he called the "Cygwin's > pipe-data bug".
Yes, this is it. Reading the above reference, the 2 processes refered to on the Cygwin end are ssh and rsync, connected via a local pipe. On a Linux/UNIX system the local rsync process would have inherited the socket connected to the rsync process on the target and thus the two rsync processes would be directly connected over the socket. The Windows environment (i.e., lack of a native fork/exec/inheritance) requires the ssh process to remain involved as a middle man, passing socket data to the local pipe and visa versa. It appears to fail in this capacity at some point, leaving both ends waiting for the other. Just as a note, due to this issue, the issue with sshd/.cygrunsrv utilizing 100% of the CPU on occasion, the ssh -X/-Y hang issue, and slow bash startup with real-time virus/spyware detection active, I was forced to find an alternative, I found OpenVPN. Once two systems are securely and privately connected, any protocol can be used, for instance VNC (vs. X forwarding), rsyncd (vs. rsync over ssh), direct file system mounting and so on. OpenVPN has reasonable, UNIX like control so that the connection can be established on demand or continuous as needed and can be routed over a single socket connection like ssh, both OpenVPN and ssh ride over OpenSSL. I've noticed that once Cygwin is removed from a given system, virus scans, spyware scans and disk defragmention speed dramatically improve. I've not investigated, but I believe this is due to the large number of small files in the Cygwin directory hierachy, which is natural in a Linux/UNIX like environment. I would have prefered to have used Cygwin, at this point it is all but eliminted from production systems that I maintain as it has proven too problematic, perhaps (I hope) this will change in the future. I continue to use Cygwin in my personal environment and follow this list. Brett -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/