Trojan Horses

[A. Lester Buck]

In article <8645:Oct2521:49:5790 at kramden.acf.nyu.edu>, brnstnd at kramden.acf.nyu.edu (Dan Bernstein) writes:
> In the *particular* case of close(), I just ignore errors that I don't
> know how to handle. After all, I use close() merely to indicate to the
> system that I'm done with a descriptor. (That is what it's meant for---
> right?)

No, it is also meant for the sytem to tell you that your file entered
a stable state, which is a much more important use now that processes
can have hundreds of files open.

> There's no good
> way to handle EDQUOT if it comes up---even if I had some reason to
> suspect that close() could return the error, I simply *cannot* replay
> data that might have been buffered in the same file by a previous
> process. Tell me: Why should I handle EDQUOT? Why should I interpret it
> as some sort of error? Who benefits if I thrash about upon this error?
> ---Dan

Your data is probably quite safe in the filesystem, but the quota
machinery just won't let it be closed.

I can think of several ways to handle an EDQUOT error on close, depending
on how much work has just gone into computing the contents of the file.

For an interactive user, we back off and fire up a shell prompt with
the message "Over quota: delete other files, abort, retry? :-)" with
appropriate machinery to allow the user to make an intelligent
decision.  For a non-interactive user who just spent $1000 of compute
time on this file, I might suggest running a .overquotarc file in
their root directory, or deleting the largest, oldest files under
the assumption that they can be recovered from system backups, or
send mail to the user, wait for a human to come by and mount a tape,
then lseek to the beginning of the file and write it to tape.

The idea that there is "no good way to handle EDQUOT" is bogus.
I am not proposing that every application offer this functionality,
only that some important applications might need, and should certainly
be given the opportunity, to recover from an error on close.

-- 
A. Lester Buck    buck at siswat.lonestar.org  ...!uhnix1!lobster!siswat!buck