Eliot Moss wrote:
Eliot Moss wrote:
Tried two more things ...
- rsync in the opposite direction fails in the same way
- adding --protocol=29 (to match the remote end) did not
change the behavor
Unfortunately no other version of rsync is available with
cygwin 1.7.x, so I can't simply install an earlier version.
I think I'll need to obtain source and build it myself.
Maybe later today ....
Rebuilding from source had no effect -- I did apply first
the 3.0.6-1.src patch and then the cygwin patch.
So I tried strace to get more info. The first failure is
at a dup2 call immediately after a fork() call. The dup2
args are (3, 0) and Win32 returns error 6, which cygwin
translates to 9 (EBADF). Near as I can tell, fd 3 is a
socket.
The code is in piped_child in pipe.c; here is the comment
at the top of that routine:
/**
* Create a child connected to us via its stdin/stdout.
*
* This is derived from CVS code
*
* Note that in the child STDIN is set to blocking and STDOUT
* is set to non-blocking. This is necessary as rsh relies on stdin
being blocking
* and ssh relies on stdout being non-blocking
*
* If blocking_io is set then use blocking io on both fds. That can be
* used to cope with badly broken rsh implementations like the one on
* Solaris.
**/
Not sure if I am reporting the most helpful stuff, but there
it is. Any ideas on how I can help resolve this? There does
not seem to be anything like this reported in the rsync list,
so I think it's particular to cygwin, and probably to 1.7.x.
Btw, this seems related to the rsync problem on close, for which
there was discussion back in August (msg 153806 is at the end of
that thread).
Cheers -- Eliot
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
