mjr@gildor.dco.dec.com (Marcus J. Ranum) (10/22/90)
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
malc@iconsys.uucp (Malcolm Weir) (10/27/90)
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. > As I understand it, under bog standard *nix System V, and 4.2 for that matter, running on disk-rich workstations (i.e. without NFS), it is perfectly possible for data to be lost long after the write(2) has occurred, the close(2) has been performed, and the process itself having retired to a little cottage in the country to end its days in comfort, with each operation gleefully reporting success and basically life to be wonderful. 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... Error returns? Luxury. They may be too late to do anything, but its better than *not* telling you! Malc. P.s. How about a "Call for Votes" on whether "comp.unix.internals" should be renamed and re-chartered as "comp.whining.wingeing.noisy.bastards"? ":-)" Intentionally left out.
jfh@rpp386.cactus.org (John F. Haugh II) (10/28/90)
In article <1990Oct27.023618.5495@iconsys.uucp> malc@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@rpp386.cactus.org "SCCS, the source motel! Programs check in and never check out!" -- Ken Thompson