Mail Archives: cygwin/2006/04/27/07:50:56
> 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/
- Raw text -