On the silliness of close() giving EDQUOT

Robert Thurlow thurlow at convex.com
Fri Oct 19 12:28:34 AEST 1990


In <24048:Oct1822:23:2090 at kramden.acf.nyu.edu> brnstnd at kramden.acf.nyu.edu (Dan Bernstein) writes:

>["I don't mind close returning -1/EINTR and -1/EBADF."]
>No other close() errors make sense.

So how do you pick up errors on asynchronous writes?  You are never
going to know about them if close can't return an error here.  It makes
sense to do an implicit fsync on close, and I think the error code from
that operation has to be propagated.  You may not be able to do a lot
of constructive rebuilding in this case, but your program can at least
let the user know that, "hey, something really evil happened."  I'd
shoot a program (like Berkeley's "cp") that didn't at least let me know
via an exit status.  You may choose to let your program retry the close
until it works, too.

>EDQUOT can and should be detected immediately upon the write() that
>triggers it.

This probably can be arranged, though it takes some care to not get
hosed by multiple processes.

>Perhaps you don't yet see how silly that is. Has it occurred to you that
>the application may have erased the data that it wrote to disk? Are you
>going to insist that every write() be backed up by temporary buffers
>that accumulate a copy of all data written until the program dies? Well?

This is ridiculous.  If a program wants to _know_ the data is secured,
it can call fsync before it frees the buffers or overwrites the data.
If you don't care enough about the data to do this, go another step
and cast the return value of close to "void".

>``But then it has to send a request immediately over the network and
>wait to find out how much space is left!'' you say. Not so. Does TCP
>force each side to stay synchronized on every packet? Of course not. The
>file server can just pass out ``allocations'' of disk space.

"Allocations"?  I won't lightly put *any* state into my NFS server, never
mind state to take care of frivolities like close returning EDQUOT.

Rob T
--
Rob Thurlow, thurlow at convex.com or thurlow%convex.com at uxc.cso.uiuc.edu
----------------------------------------------------------------------
"This opinion was the only one available; I got here kind of late."



More information about the Comp.unix.internals mailing list