Path: utzoo!utgpu!water!watmath!egisin
From: egisin@watmath.waterloo.edu (Eric Gisin)
Newsgroups: comp.emacs
Subject: Re: GNUemacs on SUNS: full partitions and NFS timeouts
Message-ID: <16891@watmath.waterloo.edu>
Date: 11 Feb 88 19:51:26 GMT
References: <13252@cornell.UUCP> <3920@hall.cray.com>
Distribution: comp
Organization: U of Waterloo, Ontario
Lines: 22

In article <3920@hall.cray.com>, hrp@hall.cray.com (Hal Peterson) writes:
> We ran into this, too.  I think it's either a bug in SunOS or a problem
> in the mapping from NFS to UNIX(R) system calls.  What should happen is
> this: the write(2) call to save the buffer returns -1 with ENOSPC.  Instead,
> the write call says that everything is OK, and the fsync(2) call gives
> the ENOSPC error.  This is especially interesting since, according to the
> man page, ENOSPC isn't one of the choices for fsync.  Anyway, the GNU
> Emacs code checks the return value of the write, but not of the fsync,
> resulting in the observed symptom.

Emacs is broken if it doesn't check the status of fsync(),
it could return EIO on a non-NFS system.

The reason write doesn't return ENOSPC on an NFS file system is NFS's write behind. 
So write() doesn't wait for the RPC reply containing the error.
On a local file system the check for ENOSPC is made when write() allocates a block.

To correctly check for all write errors on a NFS or non-NFS system
probably requires doing a fsync() before the close() and checking it's value.
> 
> Long term fix:  fix SunOS.  In the meantime, though, it wouldn't hurt to
> check the return value from fsync.