checking close's return value

Michael I. Bushnell mike at turing.unm.edu
Thu Sep 22 17:02:35 AEST 1988


In article <1988Sep20.230150.7574 at utzoo.uucp>, henry at utzoo (Henry Spencer) writes:
>In article <20981 at watmath.waterloo.edu> rbutterworth at 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 at turing.unm.edu
       /  \ {ucbvax,gatech}!unmvax!turing.unm.edu!mike



More information about the Comp.unix.wizards mailing list