Truncated output from "rsync -e ssh ... 2>&1 | tee"

[David Evers]

>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/bug-cvs@gnu.org/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