Trojan Horses

[Dan Bernstein]

In article <1990Oct26.005843.12463 at athena.mit.edu> jik at athena.mit.edu (Jonathan I. Kamens) writes:
> In article <8645:Oct2521:49:5790 at kramden.acf.nyu.edu>, brnstnd at kramden.acf.nyu.edu (Dan Bernstein) writes:
> |> Now let's take an error matching my quoted description. close() is not
> |> documented as returning EDQUOT.
> "The close(2) man page (at least on my system) has not been updated to reflect
> the fact that close() can return EDQUOT.  Just like it doesn't say (at least
> on my system) that close can return EINTR.  I have to check for EINTR, even
> though it isn't documented, but I don't have to check for EDQUOT."

Are you trying to restate what I said? Okay, here's your mistakes.

Sentence 2: My man page does say that close() can return EINTR.

Sentence 3: I have *never* said that I have to check for EINTR. It's
reasonable to expect a programmer to check for EINTR, because there's a
good handling method: to restart the system call. But this is not
something I have to do, particularly in programs where close() cannot be
interrupted by signal handlers.

In other words, I do *not* have to check for *any* error. This applies
to EINTR and EDQUOT.

The difference between EINTR and EDQUOT is that there's a sensible way
to handle the first. As I explain in a previous article, there is no
correct way to handle the second, short of requiring every single
program to fsync() as if EDQUOT were EIO.

> |> There's no logical reason to expect it
> |> to return EDQUOT
> "In my opinion, there is no logical reason to expect it to return EDQUOT."

What is this with you and your wimpy presentation style? Of course it's
my opinion; do you think I'd say something if I had a different opinion?

> So, your program can
> either accept the decision they've made, and be more robust,

Sorry, bud. You're wrong.

> |> ---even if write()'s buffering weren't hidden below its
> |> interface, it could easily return the error accurately.
> "In my opinion, it should be possible to implement any filesystem, local or
> remote, so that the kernel can always return quota errors to a user
> process immediately upon write(), and not delay them until close()."

This is true for every currently operating filesystem I know about.

> You suggested one possible way to do this in another posting, Dan, and I asked
> you to expand on it, since I didn't understand what you were saying.  I have
> seen no response to my request.  Why not?

Sorry, I've been saving up a few articles to respond to in a batch. I
thought the analogy to TCP windowing was reasonably clear.

>   3. The kernel has to "reserve" space on the remote filesystem before
> performing any file operations, and "ask" for more space whenever it uses up
> the space it's asked for.

Yep.

>   3. Have you ever rented a car?  You know how they put a really big
> almost-charge (I forget what the word they use for it is) on they credit card
  [ continues the interesting analogy ]

Are you assuming that network filesystem programmers aren't intelligent
enough to fix these failures, perhaps along the lines I explain in a
previoius article?

> You have asserted, as fact, that there is no good way, and
> yet I can give you any number of examples of programs that have found a good
> way.

I have asserted, as opinion, that there is no good way. In a previous
article I challenge you to demonstrate that good way in an important
class of cases where I'm pretty sure it's impossible.

I agree that it may be possible to handle EDQUOT on close() properly in
the special case that you've opened the file you're accessing, and you
know that no other process is writing to the same system buffer.

> You're living in a fantasy world, Dan.  You don't want close() to return
> EDQUOT.  Well, it does.  Either your programs deal with that fact, or they
> fail inexplicably.

Naw. Take pty, for example. It will not ``fail inexplicably'' because a
close() fails with EDQUOT. It'll just have one fewer descriptor to play
with. As it isn't descriptor-happy like some programs (e.g., more), this
simply *cannot* cause a failure---pty only closes a few (I think at most
four) descriptors it gets from the outside, and them only upon exiting.
Where's the problem?

> |> Do you check the return value of assert()?
> This is just stupid, and it's just like your argument about setuid() returning
> ENOENT.

As both this and the ENOENT argument were satires of your continual
failure to present rational justifications for your statements, I agree
entirely.

---Dan