Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!uwm.edu!uakari.primate.wisc.edu!aplcen!ginosko!uunet!auspex!guy
From: guy@auspex.auspex.com (Guy Harris)
Newsgroups: comp.unix.questions
Subject: Re: Re: Finding diskspace status programatically.
Message-ID: <2443@auspex.auspex.com>
Date: 13 Sep 89 16:50:39 GMT
References: <10651@dasys1.UUCP> <10650070@hpisod2.HP.COM>
Reply-To: guy@auspex.auspex.com (Guy Harris)
Organization: Auspex Systems, Santa Clara
Lines: 25

>Except that if you want to port it to BSD, you'll find your program
>failing in mysterious and wonderful ways, because although a function of the
>same name is present, the number and types of the arguments are
>different.

Really?  It's not in the 4.3-tahoe source I have.  Perhaps you mean
"Except that if you want to port it to systems not derived from S5R3
that have picked up the Sun NFS code"?

>Good going, folks.

No argument with that - the SunOS "statfs" may not have been perfect,
but it was somewhat of a *de facto* standard, so AT&T should have
refrained from "improving" it in incompatible ways, or given it a
different name after having done so.

I expect S5R4 to have a "statvfs" function, which will be improved from
"statfs", but will also have a different name.  With any luck, OSF will
pick it up (with any luck, AT&T won't stop them), and it'll stand a
chance of fixing AT&T's botch....

(Now if they'd just fix their botch with "rmdir", and have it return
ENOTEMPTY when you try to remove a non-empty directory, as did the *de
facto* standard 4.[23]BSD version, instead of returning EEXIST as S5R3
does....)