somani@parns.nsc.com (Anil Somani) (08/25/89)
What is the best way to find out current available diskspace
from within a program? One way is -
system("df . > /tmp/somename");
and then parse the file /tmp/somename.
I am sure there is a better way. I am using SunOS 4.0.3.
thanks in advance,
-Anil
--
Anil Somani uucp: {sun|hplabs|amdahl|decwrl}!nsc!parns!somani
National Semiconductor Domain: somani@parns.nsc.com
2900 Semiconductor Dr. Corporate Design Automation, M/S D3-677
Santa Clara, CA 95052-8090 Phone: (408)721-4146jpr@dasys1.UUCP (Jean-Pierre Radley) (09/07/89)
In article <146@beta.nsc.com> somani@parns.nsc.com (Anil Somani) writes: >What is the best way to find out current available diskspace >from within a program? One way is - > system("df . > /tmp/somename"); Have you tried the ustat() call? It uses the ustat structure which looks like this: struct ustat { daddr_t f_tfree; /* total free blocks */ ino_t f_tinode; /* total inodes free */ char f_fname[6]; /* filsys name */ char f_fpack[6]; /* filsys pack name */ }; -- Jean-Pierre Radley jpr@jpradley.uucp New York, NY 72160.1341@compuserve.com
tjo@fulcrum.bt.co.uk (Tim Oldham) (09/11/89)
In article <10651@dasys1.UUCP> jpr@dasys1.UUCP (Jean-Pierre Radley) writes: >In article <146@beta.nsc.com> somani@parns.nsc.com (Anil Somani) writes: >>What is the best way to find out current available diskspace >>from within a program? > >Have you tried the ustat() call? AT&T UNIX System V Programmer's Reference Manual, statfs(2): "statfs obsoletes ustat and should be used in preference to it in new programs." Much better all round. Tim. -- Tim Oldham tjo@fulcrum.bt.co.uk or ...!mcvax!ukc!axion!fulcrum!tjo #include <stdisclaim> Why have coffee, when caffeine tastes this good?
decot@hpisod2.HP.COM (Dave Decot) (09/13/89)
> AT&T UNIX System V Programmer's Reference Manual, statfs(2): > > "statfs obsoletes ustat and should be used in preference to it in new > programs." > > Much better all round. 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. Good going, folks. Dave
guy@auspex.auspex.com (Guy Harris) (09/13/89)
>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....)