Path: utzoo!utgpu!news-server.csri.toronto.edu!clyde.concordia.ca!uunet!crdgw1!rpi!uupsi!sunic!kullmar!pkmab!ske From: ske@pkmab.se (Kristoffer Eriksson) Newsgroups: comp.unix.internals Subject: Re: Trojan Horses Message-ID: <4315@pkmab.se> Date: 19 Oct 90 07:39:20 GMT References: <1990Oct18.121818.9956@athena.mit.edu> <19547:Oct1818:25:2690@kramden.acf.nyu.edu> Organization: Peridot Konsult i Mellansverige AB, Oerebro, Sweden Lines: 17 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(). It's not right >to give the programmer the burden of working around NFS's bugs. Same for AFS. If I remember correctly, physical I/O-errors are sometimes reported not on the write() that wrote the data that provoked the error, but on the next I/O-call. This is because the data is buffered in the filesystem cache before it is physically written out, and the error may occur after the write() has already returned. The error is reported back to the application at the first opportunity after it occured, and this may sometimes be the close() call. Also, close() may flush buffered data from the cache, wich can also result in new I/O-errors. Therefore, close() can fail on any filesystem, even local ones, and should always be checked (provided that you care about your data). -- Kristoffer Eriksson, Peridot Konsult AB, Hagagatan 6, S-703 40 Oerebro, Sweden Phone: +46 19-13 03 60 ! e-mail: ske@pkmab.se Fax: +46 19-11 51 03 ! or ...!{uunet,mcsun}!sunic.sunet.se!kullmar!pkmab!ske