Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com From: "Bob Byrnes" Date: Fri, 19 Nov 2004 11:48:37 -0500 In-Reply-To: from =?iso-8859-1?Q?J=F6rg_Schaible?= (Nov 19, 9:55am) Organization: Curl Corporation X-Address: 1 Cambridge Center, 10th Floor, Cambridge, MA 02142-1612 X-Phone: 617-761-1238 X-Fax: 617-761-1201 To: cygwin AT cygwin DOT com Subject: RE: scp exits often with -1 Message-Id: <20041119164837.6AA11E53E@wildcard.curl.com> 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/