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

Jonathan I. Kamens jik at athena.mit.edu
Tue Oct 30 07:28:11 AEST 1990


In article <1990Oct29.142933.5893 at dg-rtp.dg.com>, hunt at 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 at Athena.MIT.EDU				Allston, MA  02134
Office: 617-253-8085			      Home: 617-782-0710



More information about the Comp.unix.internals mailing list