🚀 go-pugleaf

In article <109685@convex.convex.com> tchrist@convex.com (Tom Christiansen) writes:
  [ checking write errors ]
> Cat and col are two utilities I've just caught doing this.  Cat does
> make a stab at detecting this, but it does it wrong.  It just checks
> ferror(stdout), but it's never done an fflush() or an fclose() first.

That's true. However (old discussion resurfacing again), what happens if
another process has the file open, so things don't get written to disk
until that process closes the file? There is simply no way to recover
the data. fsync()ing all the data just to test for things like EDQUOT,
ENOSPC, etc. would be a huge overhead.

You have two strategies for solving this:

1. Replace NFS with a sane remote filesystem, so that you get quota and
space errors on the write()s that trigger them. Unfortunately, it's a
bit difficult to simply throw away NFS at some sites, so go on to #2.

2. Write a program that does nothing but create a file on disk, read
input, and write output to the file, checking all errors. Give the
program options, so that it can do things like fsync if you want, or
write the file to another disk and put in a symbolic link if you run out
of space, or send you a mail message and buffer output in memory as long
as it can hold out. Or whatever.

After #2, you'll notice that a lot of programs can be drastically
simplified, because they don't have to open files for writing. Meanwhile
errors like the one you're complaining about will disappear. Meanwhile
you'll be able to get programs to work with new filesystems, or
networks, or whatever, just by using a different program. Guess what?
This works for reading files as well. Guess what? It also works for
networks (see my auth and authutil packages). Guess what? There really
is an advantage to modularity.

> Plus it only says "output write error", not what the error is.

stdio's fault. cat should use read() and write() for efficiency and
error checking, but that means a rewrite that nobody's bothered doing. 

> My first question I have is what could possible break if cat were to do
> an fclose(stdout) at the end (and check the status and set the exit 
> accordingly).  

There's nothing wrong with the change, but it doesn't solve the problem
unless you're guaranteed to be the only writer.

> My second question is whether this is just a symptom of sloppy programming
> or whether there's some reason why filters (mis)behave this way.

Although management at Sun might wish otherwise, UNIX was not rewritten
from scratch when NFS was released upon the world.

---Dan