I spent a little time looking at these straces and scp -v output. I still don't understand what's going on, but it seems to be unrelated to the recent pipe changes. I say that because those changes only affected select for writes on pipes, and the problem seems to be on the read side. It looks like scp and ssh are sending only single bytes across the pipe when the failure occurs, so the pipe is almost empty, and (correctly) always selects writable anyway. Something is making the pipe disappear, causing PeekNamedPipe to fail for the ssh process in the select for read on pipes code (which has not been changed).
Either something is going catastrophically wrong with the pipe at a very low level, or the scp process is closing it in a way that ssh does not expect. So far, I can't tell which is happening, but I did note one significant difference in the scp -v output: only the "good" invocation has ... debug1: client_input_channel_req: channel 0 rtype exit-status reply 0 An examination of the ssh sources to see what this means might be enlightening, but I don't have time to do that right now. -- Bob -- 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/