Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!swrinde!cs.utexas.edu!milano!uudell!sequoia!rpp386!jfh
From: jfh@rpp386.cactus.org (John F Haugh II)
Newsgroups: comp.unix.aix
Subject: Re: Control NFS exported filesystems
Summary: open that APAR ...
Message-ID: <19398@rpp386.cactus.org>
Date: 24 Jun 91 13:46:01 GMT
References: <91169.000329CALT@SLACVM.SLAC.STANFORD.EDU> <8567@awdprime.UUCP> <1991Jun20.090136.14351@ioe.lon.ac.uk>
Organization: River Parishes Programming, Austin TX
Lines: 29

In article <1991Jun20.090136.14351@ioe.lon.ac.uk>, teexand@ioe.lon.ac.uk (Andrew Dawson) writes:
> In <1991Jun19.162331.25505@bellcore.bellcore.com> jona@iscp.Bellcore.COM (Jon Alperin) writes:
> 
> >	Hey...maybe this explains the reason that when I save a file
> >under VI which is kept on another NFS partition, VI tells me that it
> >was able to save the file, but because the real physical disk was full I
> >end up with a 0 length file (and lose all my work).....
> 
> This sounds like something we have been discussing with IBM recently. I think
> essentially the client is cacheing requests, so although write() returns
> sucessfully, the data hasn't been written to disk. Your application may pick
> up an error if fsync is called, and the close should also fail (not that many
> applications check this). However, I'm not sure even this much worked until
> we'd applied an APAR fix.

There have been problems with "vi" and other applications which do not check
the return status of "close" when using NFS on certain file systems.  For
example, I worked on an APAR where "vi" of a file on an NFS-mounted MVS file
system failed if the file was extended.  The solution was, as I recall, to
have fsync() called and to check its return status.

I'd suggest that anyone who finds a problem where a program thinks it has
exited successfully, but the data wasn't written, open an APAR.  The cause
will probably be very similiar.
-- 
John F. Haugh II        | Distribution to  | UUCP: ...!cs.utexas.edu!rpp386!jfh
Ma Bell: (512) 255-8251 | GEnie PROHIBITED :-) |  Domain: jfh@rpp386.cactus.org
"UNIX signals are not interrupts.  Worse, SIGCHLD/SIGCLD is not even a UNIX
 signal, it's an abomination."  -- Doug Gwyn