Path: utzoo!attcan!uunet!tut.cis.ohio-state.edu!att!pacbell.com!decwrl!bacchus.pa.dec.com!decuac!gildor.dco.dec.com!mjr
From: mjr@gildor.dco.dec.com (Marcus J. Ranum)
Newsgroups: comp.unix.internals
Subject: write/close (was Re: Trojan Horses)
Message-ID: <1990Oct21.171227.17356@decuac.dec.com>
Date: 21 Oct 90 17:12:27 GMT
References: <BZS.90Oct17215707@world.std.com> <1990Oct18.121818.9956@athena.mit.edu> <35111@cup.portal.com>
Sender: news@decuac.dec.com (Network News)
Organization: Digital Equipment Corp., Washington ULTRIX Resource Center
Lines: 20

In article <35111@cup.portal.com> ts@cup.portal.com (Tim W Smith) writes:

>In summary, this behaviour of a file system is not acceptable.

	I couldn't agree more - but sometimes you find yourself in a
position where you have to make a program *WORK* reliably on an OS
that may have some "unacceptable" features. You then have a few options:
unemployment, fixing the OS yourself, or coding around the "features".
(this is known as the "'sh** happens' school of functional programming")

	Checking the return values of system calls that return a value
to indicate a failure is one way a serious programmer can prevent his
or her software from having "unacceptable features" like becoming
inconsistent, or crashing and burning.

mjr.
-- 
Nothing is beautiful unless it is large. Vastness and immensity can make
you forget a great many weaknesses.
	- Emperor Napoleon I, predicting the development of X-window in 1813