Richard Stallman <[EMAIL PROTECTED]> writes: > CVS uses stdio, and stdio doesn't work very well with non-blocking > file descriptors. CVS can detect the error easily enough, but at that > point stdio has already thrown away the buffer full of data, and CVS > hasn't recorded it anywhere. While in principle CVS could switch to > not use stdio, that would be a fairly substantial change. > > Many programs use stdio, and these programs ought to work when run > under ssh. This suggests that ssh and stdio are responsible for the > problem, and one or the other of them should be fixed.
When programs are run under ssh, they will work correctly. This is a different case. CVS is invoking ssh in a child process in a way which causes them to share file descriptor 2. ssh is then unblocking file descriptor 2 in a way which CVS does not expect. This type of problem can only happen with programs which invoke ssh. > It would be best to fix stdio, I think. What platform is CVS running > on when it fails? Does stdio in GNU libc handle non-blocking file > descriptors properly? If not, we can fix it. The failure which I see occurs on GNU/Linux using GNU libc 2.2.5. Specifically, in new_do_write() in libio/fileops.c, if the call to _IO_SYSWRITE() (i.e., write()) fails for any reason, including EAGAIN, the contents of the output buffer are discarded. Ian _______________________________________________ Bug-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-cvs
