Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!snorkelwacker!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.121818.9956@athena.mit.edu> Date: 18 Oct 90 12:18:18 GMT References: Sender: daemon@athena.mit.edu (Mr Background) Reply-To: jik@athena.mit.edu (Jonathan I. Kamens) Organization: Massachusetts Institute of Technology Lines: 40 In article , bzs@world.std.com (Barry Shein) writes: |> >I wonder, incidentally, why does close() return something? Is it just that |> >it's a system call? What checks for close()'s return value? I could see it |> >being used for security checks and such, I suppose (verifying that "fd %d |> >had to be closed -- CHECK THIS"). Programmers failing to check the return value of close() in their programs is one of the never-ending problems we have had here at Project Athena. If you are working on a remote filesystem (such as NFS or AFS), your file is often not completely flushed to the remote filesystem until you close it. Therefore, if you are (for example) close to your quota, and you do close(), it is quite possible that the close() will put you over your quota and therefore fail. However, programmers who don't check close() never find out that the file didn't get written because the user went over his quota, and this can have very bad effects, for example, GNU emacs 18.54 (I don't know about 18.55, we haven't switched to it yet) didn't check close() when saving files, so a user might spend several hours working on a paper, then save it (without getting any errors from emacs) and log out. The next time he logs in, the paper is empty, and all his work has been lost. A worse example is something like ispell, a spelling program that saves a copy of the original file before spell-checking it. A previous version (actually, we may not have gotten around to fixing this bug yet, I don't remember) would save both the back-up and spell-checked file without checking close()'s return value -- the result is that both files were truncated and the user left with nothing if they could not be written for some reason. Unix programmers of the world -- PLEASE do not assume that all the world's UFS and that all of the world's filesystems have the same semantics as local disks. They DON'T. Close() returns a value because it is possible for it to fail. -- Jonathan Kamens USnail: MIT Project Athena 11 Ashford Terrace jik@Athena.MIT.EDU Allston, MA 02134 Office: 617-253-8085 Home: 617-782-0710