Trojan Horses

[Jonathan I. Kamens]

In article <19547:Oct1818:25:2690 at kramden.acf.nyu.edu>, brnstnd at kramden.acf.nyu.edu (Dan Bernstein) writes:
|> This is a failure of NFS, not a reason to check close(). (Well, close()
|> should be restarted on EINTR, but that's a side issue.) It's not right
|> to give the programmer the burden of working around NFS's bugs. Same for
|> AFS.

  Hogwash.  If close() is specified as returning an error value, then it is
reasonable for it to sometimes return an error value, and it is also
reasonable for the programmer to be expected to check and deal with its return
value.

  The error is that when kernels first started getting code put into them that
would set errno to something other than EBADF in response to a close(), the
man page for close() (at least in BSD4.3, which is what I'm looking at) was
not updated to reflect the new possible errno values.  Of course, there are
other man pages besides the one for close() that don't list all possible errno
values, so that's nothing unusual.

  Just as it is reasonable for write() to return an error when the disk is
full, it is reasonable for close() to do so, and the man page should be
updated to reflect that.

  You seem to be saying that filesystems should never be allowed to postpone
writing to disk until close(), which is a completely reasonable thing for a
filesystem to want to do (*especially* remote filesystems), just because
close() should be easier for the programmer to deal with.  Feh.  The whole
world isn't UFS anymore, and to try to pretend that it is and not update our
system calls to reflect the fact that it isn't is to unnecessarily limit
progress.

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