Path: utzoo!utgpu!watserv1!watmath!att!att!dptg!ulysses!andante!mit-eddie!bloom-beacon!athena.mit.edu!jik From: jik@athena.mit.edu (Jonathan I. Kamens) Newsgroups: comp.unix.internals Subject: Re: Trojan Horses Message-ID: <1990Oct18.200939.17427@athena.mit.edu> Date: 18 Oct 90 20:09:39 GMT References: <1990Oct18.121818.9956@athena.mit.edu> <19547:Oct1818:25:2690@kramden.acf.nyu.edu> Sender: daemon@athena.mit.edu (Mr Background) Reply-To: jik@athena.mit.edu (Jonathan I. Kamens) Organization: Massachusetts Institute of Technology Lines: 35 In article <19547:Oct1818:25:2690@kramden.acf.nyu.edu>, brnstnd@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@Athena.MIT.EDU Allston, MA 02134 Office: 617-253-8085 Home: 617-782-0710