Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!mailrus!ames!hc!lanl!unm-la!unmvax!mike From: mike@turing.unm.edu (Michael I. Bushnell) Newsgroups: comp.unix.wizards Subject: Re: checking close's return value Message-ID: <1213@unmvax.unm.edu> Date: 22 Sep 88 07:02:35 GMT References: <20981@watmath.waterloo.edu> <1988Sep20.230150.7574@utzoo.uucp> Sender: news@unmvax.unm.edu Reply-To: mike@turing.unm.edu (Michael I. Bushnell) Organization: University of New Mexico, Albuquerque Lines: 43 In-reply-to: henry@utzoo.uucp (Henry Spencer) In article <1988Sep20.230150.7574@utzoo.uucp>, henry@utzoo (Henry Spencer) writes: >In article <20981@watmath.waterloo.edu> rbutterworth@watmath.waterloo.edu (Ray Butterworth) writes: >>If you are writing (or buying) software that is going to write >>to these devices, I strongly suggest you make sure that it >>checks the return value of close(). >The same comment, actually, is much more broadly applicable. It's not >at all inconceivable for devices that use the buffer cache to report an >error in asynchronous I/O by returning an error from close(). One should >always check the result from close(). Sigh. If only. The problem here is that I have *never* seen a man page for close which returns errors like EQUOT or EIO. The 4.3+NFS man page says close can only fail with EBADF, and SunOS 4.0 says that close will only fail with EBADF or EINTR. If close returns errors like EQUOT or EIO, then the man page needs to be rewritten. UNIX does *not* guarantee that hardware related errors will get reflected on write. This is one of its deficiencies, but is unavoidable given the implementation of the filesystem. The actual disk write may take place hours after the write(2) system call (assuming update isn't running). Do we resurrect the process to return an error from the close(2)? What about processes that don't explicitly close their file descriptors? That has always been acceptable practice, but now we are told we are supposed to close everything before we exit so we can check for undocumented errors. The quota problem is one that NFS did not implement very well, alas. The EIO problem is a different story...Since applications should not count on write(2) working, even if the call returned success, in the even that hardware goes bad, they should not complain about EIO being returned late. At least it was returned sometime. And if the kernel gives me EIO on a close, and the man page says nothing about it, they should NOT return that error. -- -- N u m q u a m G l o r i a D e o \ Michael I. Bushnell \ HASA - "A" division /\ mike@turing.unm.edu / \ {ucbvax,gatech}!unmvax!turing.unm.edu!mike