Path: utzoo!attcan!uunet!lll-winken!sun-barr!apple!usc!rutgers!cmcl2!kramden.acf.nyu.edu!brnstnd
From: brnstnd@kramden.acf.nyu.edu (Dan Bernstein)
Newsgroups: comp.unix.internals
Subject: Re: Trojan Horses
Message-ID: <8536:Nov600:37:2790@kramden.acf.nyu.edu>
Date: 6 Nov 90 00:37:27 GMT
References: <1893@necisa.ho.necisa.oz> <8645:Oct2521:49:5790@kramden.acf.nyu.edu> <1914@necisa.ho.necisa.oz>
Organization: IR
Lines: 36

In article <1914@necisa.ho.necisa.oz> boyd@necisa.ho.necisa.oz (Boyd Roberts) writes:
> It is an error because close() returned -1.

Are you paying attention? It is *not* a failure for my program to ignore
a close() error; it performs properly, complies with all the standards,
etc. My program does not receive any information from close() that
matters for the correctness of its operation. Your repeated assertions
like

> You have no other logical choice.

are absolutely ridiculous.

Suppose I admit that I'm supposed to report an error. In this case, the
program does not have any connection with the user. It would be
inappropriate to use syslog because the program cannot afford to block
and syslog is unreliable. As I asked before, what do I gain by thrashing
about if close() returns EDQUOT?

The situation would be different if I opened and closed lots of files.
Then the operation of my program might be jeapordized by a failing
close(). But that isn't the case here.

The situation might be different if I had opened and written to the file
I'm closing. If I know nobody else has written to the file, I can
reasonably recover from an EDQUOT error upon close(). But that isn't the
case here.

You say that you *must* inform the user of an error. Have you ever seen
the quota system in action? Did you notice that the kernel blares some
obnoxious messages at the user to indicate quota-related write errors?

I think you just post for the hell of it, Boyd. You like playing Devil's
Fool.

---Dan