write/close
John F. Haugh II
jfh at rpp386.cactus.org
Sun Oct 28 11:50:59 AEST 1990
In article <1990Oct27.023618.5495 at iconsys.uucp> malc at iconsys.uucp (Malcolm Weir) writes:
>Consider what happens when your machine is informed that the disk has a BAD
>SECTOR, or worse, that someone has emptied their morning coffee into your
>drive cabinet and the drives have quit in protest...
such arguments are normally pointless - what happens, for example, if the
machine room is struck with a nuclear warhead? in the most pathological
case, consider what happens if the machine register containing the result
of the test is suddenly struck by a high energy subatomic particle and
the result is changed from false to true. please - limit arguments to
likely events. how many times last week did you pour coffee into that
cpu cabinet??? i would hope the answer is none.
>Error returns? Luxury. They may be too late to do anything, but its better
>than *not* telling you!
well yes, error detection is often quite polite. error recovery is often
complex enough to be impossible. in the case of write/close errors, it
would be nice if the editors warned you your file wasn't written out
completely so you might have a chance to write it out on another more
reliable file system. the human mind is far more capable of performing
error recovery in a case like this than any piece of software.
the worst thing is that "impossible" conditions are seldom documented
as such.
--
John F. Haugh II UUCP: ...!cs.utexas.edu!rpp386!jfh
Ma Bell: (512) 832-8832 Domain: jfh at rpp386.cactus.org
"SCCS, the source motel! Programs check in and never check out!"
-- Ken Thompson
More information about the Comp.unix.internals
mailing list