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