When a write() is performed on a local file, any error condition associated with that write() is reported when the write() returns. However, it may not be possible for implementations of remote file systems, which cache data on the client and/or the server for performance considerations, to report all error conditions from write() when the write() returns. For example, the ENOSPC error condition from write() indicates that the file system is full. With a local file, this can be discovered easily when each write() takes place.
However, when the write() is to a remote file and the client implementation caches data for that file, it is not usually known until sometime later that the file system on the server, to which the file belongs, has filled. This is because the data from a write() to a remote file is actually written to the client cache. At some later time, the cache is emptied by sending data from several writes as a single packet to the server to be written to the file on the server's mass storage. At that time, if space on the server's file system fills, the server sends an indication to the client who then notifies the application which invoked the write(). Thus, an ENOSPC error condition may be reported to the application as an error condition returned to a write() other than the write() which actually caused the ENOSPC.
It may also happen that the ENOSPC error condition is reported on the close() of the file. This is potentially a more serious consequence for an application since most implementations do not now return an ENOSPC to a close(). As a result, most existing applications are not expecting an ENOSPC from a close().