Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!zaphod.mps.ohio-state.edu!uakari.primate.wisc.edu!aplcen!haven!adm!cmcl2!kramden.acf.nyu.edu!brnstnd
From: brnstnd@kramden.acf.nyu.edu (Dan Bernstein)
Newsgroups: comp.unix.internals
Subject: On the silliness of close() giving EDQUOT
Message-ID: <24048:Oct1822:23:2090@kramden.acf.nyu.edu>
Date: 18 Oct 90 22:23:20 GMT
References: <1990Oct18.121818.9956@athena.mit.edu> <19547:Oct1818:25:2690@kramden.acf.nyu.edu> <1990Oct18.200939.17427@athena.mit.edu>
Organization: IR
Lines: 52

In article <1990Oct18.200939.17427@athena.mit.edu> jik@athena.mit.edu (Jonathan I. Kamens) writes:
> In article <19547:Oct1818:25:2690@kramden.acf.nyu.edu>, brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes:
    [ NFS should deal with quotas correctly ]
> Hogwash.  If close() is specified as returning an error value, then it is
> reasonable for it to sometimes return an error value, and it is also
> reasonable for the programmer to be expected to check and deal with its return
> value.

That's a truism. Yes, any system call might return -1/EINTR. Yes,
close() should return -1/EBADF if the descriptor isn't open. These two
errors are documented and reasonable for close() to return, and it's
reasonable to expect the programmer to deal with them.

No other close() errors make sense.

You say that close() should be able to return -1/EDQUOT. That's hogwash.
EDQUOT can and should be detected immediately upon the write() that
triggers it. There's no reason that the system call for saying ``Okay,
forget about this descriptor, I'm done with it'' should produce an errno
saying ``But wait! I neglected to mention this to you when you actually
wrote the data, but you're out of space! Don't you dare forget about
this descriptor when you're out of space! Hold the presses!''

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?

>   Just as it is reasonable for write() to return an error when the disk is
> full, it is reasonable for close() to do so, and the man page should be
> updated to reflect that.

I fail to see your logic. Can I substitute any two system calls there?
``Just as it is reasonable for unlink() to return an error when the file
doesn't exist, it is reasonable for setuid() to do so, and the man page
should be updated to reflect that.''

Now what is your argument?

>   You seem to be saying that filesystems should never be allowed to postpone
> writing to disk until close(),

No. I am saying that there is no excuse for a filesystem to let a
program write() more than the user's quota without giving an error.

``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. Things only
slow down when you're very close to the hard limit.

---Dan