The attached patch fixes the problem by putting our stderr fd back into blocking I/O mode. I don't see why ssh should be playing with our stderr fd in the first place (since we're the one calling ssh, not the one being run by ssh). Does anyone see a problem with this change?
With this patch, isn't there a race over the non-blocking flag between the child ssh and the parent rsync? I'm not seeing how we know that ssh has finished messing with stderr by the time the patch comes to try to set it back to blocking.
More generally, there's presumably a reason why ssh wants to set its stderr non-blocking -- its internal io scheduling does seem to have been quite delicate in the past, so perhaps doing something different might upset it. Would it be worth asking the ssh people what's going on?
The clearest picture I've found of the problem is in the message at http://www.mail-archive.com/[EMAIL PROTECTED]/msg04280.html
That describes a way of ensuring that ssh and its parent have different _file objects_ (in the unix sense) for output destined for stderr, so that each process gets to set the blockingness it wants independent of the other. The downside is that something has to do the copying from ssh's stderr to the parent's stderr.
Cheers,
---- David
-- To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
