The attached patch fixes the problem by putting our stderr fd back
into blocking I/O mode.
A bit of digging in the openssh bugzilla throws up this:
http://bugzilla.mindrot.org/show_bug.cgi?id=26
which suggests that ssh really does want to keep stderr
non-blocking :-(
Cheers,
David
--
To unsub
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'
(Versions: OpenSSH_3.7.1p2, rsync version 2.6.2)
I've just encountered a situation where "rsync -v -n" appears to run
normally,
but reports many fewer file transfers than actually get done when you remove
the -n. (This is not one of the usual "-n" corner cases.)
It turns out that this only happen
