From xemacs-m  Mon Dec 16 17:44:50 1996
Received: from UCSD.EDU (mailbox2.ucsd.edu [132.239.1.54]) by xemacs.cs.uiuc.edu (8.8.3/8.8.3) with ESMTP id RAA27803 for <xemacs-beta@xemacs.org>; Mon, 16 Dec 1996 17:44:49 -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 PAA03685 for <xemacs-beta@xemacs.org>; Mon, 16 Dec 1996 15:44:50 -0800 (PST)
Received: by sdnp5.ucsd.edu (SMI-8.6/SMI-SVR4)
	id PAA12366; Mon, 16 Dec 1996 15:43:07 -0800
Sender: dmoore@sdnp5.ucsd.edu
To: xemacs-beta@xemacs.org
Subject: Re: 0 length files on full disk (I'm glad this isn't a stupid question)
References: <199612161431.JAA21057@plg.uwaterloo.ca> 	<Pine.LNX.3.95.961216225608.2312C-100000@icemark.thenet.ch> 	<199612162129.QAA25599@plg.uwaterloo.ca> 	<199612162132.NAA08243@newman> <199612162148.QAA25846@plg.uwaterloo.ca> <m2u3pm3wnf.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 15:43:06 -0800
In-Reply-To: Steven L Baur's message of 16 Dec 1996 15:19:16 -0800
Message-ID: <rvwwui5a45.fsf@sdnp5.ucsd.edu>
Lines: 44
X-Mailer: Red Gnus v0.75/XEmacs 19.14

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

> I've taken a look through the code, and both Lstream_write and
> Lstream_write_1 look like they may contain problems.  This code in
> Lstream_write looks particularly suspect:
> 
> int
> Lstream_write (Lstream *lstr, CONST void *data, int size)
> {
>   int i;
>   CONST unsigned char *p = data;
> 
>   assert (size >= 0);
>   if (size == 0)
>     return size;
>   if (lstr->buffering != LSTREAM_LINE_BUFFERED)
>     return Lstream_write_1 (lstr, data, size);
>   for (i = 0; i < size; i++)
>     {
>       if (Lstream_putc (lstr, p[i]) < 0)
>         break;                              <=================
>     }
>   return i == 0 ? -1 : 0;                   <=================
> }
> 
> This appears not to return error if up to 64k bytes could be buffered.

	Right, so the called won't know the write failed until much
later.  And of course, flushing at this point negates most of the
advantages of the buffer.  Might be able to try preallocating the space
in 4k chunks (and having the buffer grow from 0 to 64k).  Could also try
to just allocate 64k quickly by seeking a block size and writing a byte
enough times.  Can't just seek forwad 64k and write a byte though, since
that hole isn't backed with real disk.

	This is also a problem with NFS, since nfs semantics won't even
tell you if a write() failed until you've closed the file.


-- 
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.

