Path: utzoo!attcan!uunet!know!zaphod.mps.ohio-state.edu!wuarchive!mit-eddie!bloom-beacon!athena.mit.edu!jik From: jik@athena.mit.edu (Jonathan I. Kamens) Newsgroups: comp.unix.internals Subject: Re: dealing with close() errors (was Re: On the silliness of close() giving EDQUOT) Message-ID: <1990Oct29.202811.9409@athena.mit.edu> Date: 29 Oct 90 20:28:11 GMT References: <15480@hydra.gatech.EDU> <1990Oct26.050448.26816@fts1.uucp> <1990Oct29.051212.13740@athena.mit.edu> <1990Oct29.142933.5893@dg-rtp.dg.com> Sender: daemon@athena.mit.edu (Mr Background) Reply-To: jik@athena.mit.edu (Jonathan I. Kamens) Organization: Massachusetts Institute of Technology Lines: 35 In article <1990Oct29.142933.5893@dg-rtp.dg.com>, hunt@dg-rtp.rtp.dg.com (Greg Hunt) writes: |> 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(). The semantics of fsync() are not clear when discussing remote filesystems, i.e. it isn't clear for some filesystem types exactly what fsync() "should" do and what it does in reality. In AFS, for example, files are stored locally while they are being created or edited. Should fsync() make sure that the file has been flushed to the disk, or make sure that it has been sent across the network to the AFS server? As it happens, it does the latter, but the only way you can know that for sure is by experimenting (which is what I just did :-). Also, what happens if fsync() fails? Is the file descriptor valid, and is all of the data still available in the file, even though the file could not be pushed to disk? I don't know about this, which is why I'm asking.... if fsync() will cause the kernel to throw away any data that it can't save to the disk, then my suggestion to create another system call that would notify you on success *and not throw away data* on failure is still pertinent. Despite the fact that I'm not sure fsync() completely fits the bill for what I'm talking about, I must confess that until I read your message, I thought that fsync() took a FILE *, not a file descriptor, and that it simply verified that the FILE *'s buffer had ben write()ten to disk. That's fflush(), of course, not fsync(). You learn something new every day :-). -- Jonathan Kamens USnail: MIT Project Athena 11 Ashford Terrace jik@Athena.MIT.EDU Allston, MA 02134 Office: 617-253-8085 Home: 617-782-0710