dealing with close() errors (was Re: On the silliness of close() giving EDQUOT)

[John G. Myers]

People have stated on this newsgroup that if close(2) returns an error
such as EDQUOT, but releases the file descriptor (as AFS is wont to
do), then the application can do nothing to recover from the error.

This is not the case--most programs are not able to determine and/or
correct the underlying cause of any given error.  Most times, what is
important is that they find out that an error occured and report it to
the user and/or their parent process.  Also, an open file descriptor
on a file is not always necessary for recovering from an error.  For
example, there is a program which I have modified to deal more
gracefully with AFS: compress(1).

When given an argument, stock compress reads from an input file and
writes an output file.  When the output file is written, it closes it
and unlinks the input file.  If it encounters an error from write(2),
it prints an error message, unlinks the output file, and leaves the
input file alone.

Unfortunately, stock compress does not check the return value from
close(2).  If the user goes over quota, compress does not notice this
and unlinks the input file anyway.  The compress we run at
andrew.cmu.edu has been modified to check the return value of close
and deal with an error by reporting it to the user, unlinking the
output file, and leaving the input file alone.%

-----
% It also has been modified to set a magic "make sure this file gets
shipped all the way to the fileserver before returning from close()"
bit so that network communication errors will also be noticed.
--
_.John G. Myers		Internet: jgm at fed.expres.cs.cmu.edu
(412) 268-2984		LoseNet:  ...!seismo!ihnp4!wiscvm.wisc.edu!give!up
"It's not bogus, It's an IBM standard" --Esther Filderman