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

[Greg Hunt]

In article <1990Oct29.051212.13740 at athena.mit.edu>, jik at athena.mit.edu
(Jonathan I. Kamens) writes:
>
>   We can generalize that and say that there should be a flush() system
call
> that takes a file descriptor and verifies that all output to it has
been
> performed and was successful.  I believe that the hypothetical effects
of
> such
> a system call can be simulated both on NFS and AFS files by doing
lseek(fd,
> (off_t) 0, L_INCR) (substitute SEEK_CUR for L_INCR on a POSIX system,
> and/or 1
> for L_INCR on a SysV system).  A program which is paranoid about being
sure
> that data gets written to disk can therefore define a macro vwrite
that does
> something like so:
> 

Doesn't the already existing fsync() system call do what you want?  It
flushs the data buffers and any inode information to disk, and doesn't
return until it completes.  Any errors resulting from the completion
of buffered NFS operations are returned by the call as well, so it
solves some other problems mentioned about close().

Before I close() a critical file, I always code a fsync() for the file
to guarantee that the output is safely on disk.  I check for errors on
both calls and report them to the user.

Maybe the fsync() call doesn't exist in all flavors of UNIX?

I also disagree with a previous poster (whose name escapes me) about
checking error returns.  I believe that good programmers always check
for errors from all system calls, whether they're documented as 
returning errors or not.  Then you deal with those that you decide you
can handle somehow, and report any others to the user.  That way your
program won't accidently get caught by semantic changes from future OS
changes.  It's also easy to code, so it's not a big hassle.

--
Greg Hunt                        Internet: hunt at dg-rtp.rtp.dg.com
DG/UX Kernel Development         UUCP:     {world}!mcnc!rti!dg-rtp!hunt
Data General Corporation
Research Triangle Park, NC       These opinions are mine, not DG's.