Re: CVS problem with ssh

[Larry Jones]

Richard M. Stallman writes:
> 
> I'm glad to hear that the new CVS version has a fix that may prevent
> the problem.  Maybe this problem is fixed now.  But we should verify that.

It's not a fix, it's a temporary workaround that avoids the problem in
some, but not all, cases.

> It's possible that this fix is a full and correct solution.  If the
> descriptor has room for at least one byte, `write' won't return
> EAGAIN; it will write at least one byte.  It may write less than the
> whole buffer that was specified.  If the stdio code handles that case
> correctly, the results should be correct.

That depends on your definition of "correctly".  I suspect that all
stdio implementations handle short writes by immediately doing another
write for the remaining data, which in this case will immediately fail
with EAGAIN and we're back to where we started.

> If the current fix does not make it correct, please do make the larger
> fix--do your own buffering.  That is surely not really a large job.

Replacing stdio isn't a large job?!?

> As this case shows, other
> processes that share the descriptor have the reasonable expectation
> that they can take an inherited descriptor and make it non-blocking.

That is an entirely *un*reasonable expectation.  Like I said before,
nonblocking mode does not affect the descriptor, it affects the
underlying file and it violates all of the conventions of how files are
supposed to behave.  Thus, it cannot reasonably be used except under
very tightly controlled conditions -- when you know that you have
exclusive use, not just of the descriptor, but of the underlying file. 
Typically, it's used on newly-created sockets, which do satisfy those
conditions.  Ssh is trying to use it on standard descriptors that it
inherits from an unknown source that almost certainly do not satisfy
those conditions.  That's just plain wrong.  Note that rsh has always
worked just fine without using non-blocking mode for *anything*, ssh
should certainly be able to get away without using it on its standard
files.

> Rather that deciding what to fix by first placing blame, we can do
> better if we look at how we can contribute to making the system work.

Agreed, which is why we adopted the workaround.  But it's not "placing
blame", it's determining the root of the problem.

> The right program to fix, in a case like this, is whichever one we
> actually can get fixed.

No, the right program to fix is the one that's broken: ssh.

-Larry Jones

Whatever it is, it's driving me crazy! -- Calvin