Path: utzoo!attcan!uunet!tut.cis.ohio-state.edu!pt.cs.cmu.edu!fed.expres.cs.cmu.edu!jgm From: jgm@fed.expres.cs.cmu.edu (John G. Myers) Newsgroups: comp.unix.internals Subject: Re: dealing with close() errors (was Re: On the silliness of close() giving EDQUOT) Message-ID: <10898@pt.cs.cmu.edu> Date: 29 Oct 90 18:23:03 GMT References: <1990Oct29.051212.13740@athena.mit.edu> <1990Oct29.142933.5893@dg-rtp.dg.com> Organization: Carnegie Mellon University Lines: 33 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@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