>could not do any harm on any system. If it fixes the problem on GNU >systems, that's an important improvement, so why not do it? > >
It might not do any additional harm. I won't claim to understand the issue completely, but I was told that there might be data loss since EAGAIN may not mean what it is supposed to on some systems. I suppose that we would be no worse off than we are now. Exactly. Would you please install that change now? >It sounds like you can rely on stdio on a GNU system. In the loop we are avoiding, perhaps. Yes, that's what I meant. If you make this additional change, it will work reliably with GNU Libc. And if any other libc doesn't do what's necessary for reliable operation, that's a pretty clear bug in the other libc. Again, we could install loops around fwrite in handle_m, handle_e, handle_mbinary, and handle_mt and transfer most of the data coming across from the server correctly to stdout/stderr, Why do you say "most"? I think we have already established that _all_ the data will be transferred correctly. Isn't that so? but this still wouldn't handle other client output. Could you describe a case in which there would be a problem? It would have to be a case in which substantial data is forwarded from the server, but the client also generates substantial data. It really seems the much simpler solution for ssh to play nice with the standard file descriptors. It's not simple, it's impossible. The developers of Openssh don't agree with this position, and they won't make this change. We have two choices: fix it in CVS, or leave it broken for ever. The users will be much better off if it is fixed in CVS, so won't you please do so? Fixing this problem is well worth the work it would take to rewrite all the output routines of CVS. Since the change required is much less than that, the sooner it's done, the better. _______________________________________________ Bug-cvs mailing list Bug-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/bug-cvs