Path: utzoo!attcan!uunet!wuarchive!zaphod.mps.ohio-state.edu!ncar!gatech!mcnc!rti!dg-rtp!hunt
From: hunt@dg-rtp.rtp.dg.com (Greg Hunt)
Newsgroups: comp.unix.internals
Subject: Re: dealing with close() errors
Message-ID: <1990Oct30.153832.8853@dg-rtp.dg.com>
Date: 30 Oct 90 15:38:32 GMT
References: <15480@hydra.gatech.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: 40

In article <1990Oct29.202811.9409@athena.mit.edu>, jik@athena.mit.edu
(Jonathan I. Kamens) writes:
> 
>   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.
> 

You're right.  I forgot to mention in my original article that my
perspective is how the Data General DG/UX "fsync" system call works.
I don't know how other systems handle it.

>   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.

I'm not 100% certain, but from reading the DG/UX man page on fsync,
there is a clear (to me) implication that when an fsync fails the
file descriptor remains open and valid, and the data remains buffered
in the system.  If this isn't the way it works in reality, then I would
also want the new system call that you propose.

--
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.