Xref: utzoo comp.unix.internals:835 comp.unix.programmer:332
Path: utzoo!attcan!uunet!munnari.oz.au!metro!cluster!necisa!boyd
From: boyd@necisa.ho.necisa.oz (Boyd Roberts)
Newsgroups: comp.unix.internals,comp.unix.programmer
Subject: Re: Checking return values (was: Trojan Horses, NFS, etc.)
Message-ID: <1895@necisa.ho.necisa.oz>
Date: 25 Oct 90 23:38:29 GMT
References: <BZS.90Oct6191703@world.std.com> <BZS.90Oct17215707@world.std.com> <1990Oct18.121818.9956@athena.mit.edu> <19547:Oct1818:25:2690@kramden.acf.nyu.edu> <1885@necisa.ho.necisa.oz> <4315@pkmab.se> <1990Oct24.193712.8693@athena.mit.edu>
Organization: NEC Information Systems Australia Pty. Ltd.
Lines: 16

In article <1990Oct24.193712.8693@athena.mit.edu> scs@adam.mit.edu (Steve Summit) writes:
>The call I've still been ignoring the return value of (shake,
>shake, naughty, naughty) is fstat.  Anybody know when that can
>fail, as long as the file descriptor and stat buf pointer are
>valid?  Actually, don't answer that.  I'm going to listen to my
>own advice and start checking that value too, even if it "can't
>fail" today.

Good idea.  The fstat (or stat) may fail when it goes to write/read
the inode times on the file-system.  The file-system could go bad.



Boyd Roberts			boyd@necisa.ho.necisa.oz.au

``When the going gets wierd, the weird turn pro...''