On the silliness of close() giving EDQUOT

[Dan Bernstein]

In article <thurlow.656303314 at convex.convex.com> thurlow at convex.com (Robert Thurlow) writes:
> 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?

That is an excellent question. I suspect that if UNIX had truly
asynchronous I/O, my objections would disappear, as the whole system
would work much more cleanly. Somehow I'm not sure the latest mound of
P1003.4 is the right way to approach asynchronous I/O, but anyway...
``What asynchronous writes?''

  [ I object that programs can't afford to keep data around in case of ]
  [ possible problems; errors must be returned in a timely fashion ]
> 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.

I sympathize with what you're trying to say, but have you noticed that
fsync() isn't required to flush data over NFS, any more than write() is
required to return EDQUOT correctly? If write()'s errors aren't
accurate, I don't know how you expect fsync() to work.

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

No good remote file system is stateless. I think every complaint I've
heard about NFS is caused by the ``purity'' of its stateless
implementation.

---Dan