Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!gatech!prism!gt0178a
From: gt0178a@prism.gatech.EDU (Jim Burns)
Newsgroups: comp.unix.internals
Subject: Re: On the silliness of close() giving EDQUOT
Message-ID: <15480@hydra.gatech.EDU>
Date: 19 Oct 90 09:25:14 GMT
References: <1990Oct19.055913.7103@athena.mit.edu>
Organization: Georgia Institute of Technology
Lines: 23

It seems to me the close() problem is no different than the fclose()
problem. fclose() is known to do final flushing of stdio, and if you run
out of space YSOOL.

As far as quotas go, I think it is possible to check that, tho' absolute
reliablity may incur performance penalties. If quota(1) can tell you what
you are using, then either the write does the equivalent of quota(1) to
determine free=quota-used EVERY time, or it does it once at the beginning
of the program and tries to keep an accurate estimation of what you are
writing in your program. (Yuech, but it can be done.) (Then again, who
ever said addons like quotas ever seemlessly interface w/the standard
system. :-)

The much more serious problem is out of filesystem space. I've lost more
files in vi(1) than I care to remember because it didn't tell me there was
an error. (I don't use ZZ anymore - i do :w, then switch to another window
and check that it got there.) If you are going to buffer (explicitly in
stdio, or implicitly in NFS) you are going to have to expect (f)close errors.
-- 
BURNS,JIM
Georgia Institute of Technology, Box 30178, Atlanta Georgia, 30332
uucp:	  ...!{decvax,hplabs,ncar,purdue,rutgers}!gatech!prism!gt0178a
Internet: gt0178a@prism.gatech.edu