From xemacs-m  Mon Dec 16 19:07:11 1996
Received: from UCSD.EDU (mailbox1.ucsd.edu [132.239.1.53]) by xemacs.cs.uiuc.edu (8.8.3/8.8.3) with ESMTP id TAA28098 for <xemacs-beta@xemacs.org>; Mon, 16 Dec 1996 19:07:10 -0600 (CST)
Received: from sdnp5.ucsd.edu (sdnp5.ucsd.edu [132.239.79.10]) by UCSD.EDU (8.8.3/8.6.9) with SMTP id RAA21247 for <xemacs-beta@xemacs.org>; Mon, 16 Dec 1996 17:07:10 -0800 (PST)
Received: by sdnp5.ucsd.edu (SMI-8.6/SMI-SVR4)
	id RAA13019; Mon, 16 Dec 1996 17:05:27 -0800
Sender: dmoore@sdnp5.ucsd.edu
To: XEmacs Beta Mailing List <xemacs-beta@xemacs.org>
Subject: Re: Writing at end of disk -- critical XEmacs bug
References: <m2n2ve3ul0.fsf@altair.xemacs.org> <m2k9qi3sje.fsf@altair.xemacs.org>
X-Face: "oX;zS#-JU$-,WKSzG.1gGE]x^cIg!hW.dq>.f6pzS^A+(k!T|M:}5{_%>Io<>L&{hO7W4cicOQ|>/lZ1G(m%7iaCf,6Qgk0%%Bz7b2-W3jd0m_UG\Y;?]}4s0O-U)uox>P3JN)9cm]O\@,vy2e{`3pb!"pqmRy3peB90*2L
From: David Moore <dmoore@UCSD.EDU>
Date: 16 Dec 1996 17:05:26 -0800
In-Reply-To: Steven L Baur's message of 16 Dec 1996 16:48:05 -0800
Message-ID: <rvvia256ax.fsf@sdnp5.ucsd.edu>
Lines: 51
X-Mailer: Red Gnus v0.75/XEmacs 19.14

Steven L Baur <steve@miranova.com> writes:

> lstream.c:
> int
> Lstream_flush_out (Lstream *lstr)
> {
>   int num_written;
> 
> ...
>       num_written =
> 	(lstr->imp->writer) (lstr, lstr->out_buffer, size);
>       if (num_written == 0)
> 	/* If nothing got written, then just hold the data.  This may
> 	   occur, for example, if this stream does non-blocking I/O;
> 	   the attempt to write the data might have resulted in an
> 	   EWOULDBLOCK error. */
> 	return 0;
>       else if (num_written >= lstr->out_buffer_ind)
> 	lstr->out_buffer_ind = 0;
>       else if (num_written > 0)            <===========
> 	{                                  <===========
> 	  memmove (lstr->out_buffer, lstr->out_buffer + num_written,
> 		   lstr->out_buffer_ind - num_written);
> 	  lstr->out_buffer_ind -= num_written;
> 	}
>       else
> 	/* If error, just hold the data, for similar reasons as above. */
> 	return -1;
>     }
> 
>   if (lstr->imp->flusher)
>     return (lstr->imp->flusher) (lstr);
> 
>   return 0;
> }

	Well, it's not a bug that it doesn't explicitly return -1 there,
since some streams (like sockets) will return a short write count,
without it meaning anything is wrong.  You are simply expected to try
writing again.

	When it falls into that case, it updates the remaining count and
loops back up for another attempt to write it out.  In the case of your
disk, that second pass should be failing on the write which causes the
-1 to be returned.  Is the write() call returning 0 on that second pass?

-- 
David Moore <dmoore@ucsd.edu>       | Computer Systems Lab      __o
UCSD Dept. Computer Science - 0114  | Work: (619) 534-8604    _ \<,_
La Jolla, CA 92093-0114             | Fax:  (619) 534-1445   (_)/ (_)
<URL:http://oj.egbt.org/dmoore/>    | In a cloud bones of steel.

