Path: utzoo!attcan!uunet!decwrl!mcnc!rti!dg-rtp!hunt From: hunt@dg-rtp.rtp.dg.com (Greg Hunt) Newsgroups: comp.unix.internals Subject: Re: dealing with close() errors (was Re: On the silliness of close() giving EDQUOT) Message-ID: <1990Oct29.142933.5893@dg-rtp.dg.com> Date: 29 Oct 90 14:29:33 GMT References: <15480@hydra.gatech.EDU> <1990Oct26.050448.26816@fts1.uucp> <1990Oct29.051212.13740@athena.mit.edu> Sender: usenet@dg-rtp.dg.com (Usenet Administration) Reply-To: hunt@dg-rtp.rtp.dg.com Organization: Data General Corp., Research Triangle Park, NC Lines: 46 In article <1990Oct29.051212.13740@athena.mit.edu>, jik@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@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.