[f]statvfs (was Re: bug in statfs)

[Brian Ford <ford at vss dot fsi dot com>]

On Thu, 4 Dec 2003, Sam Steingold wrote:
> Corinna Vinschen [2003-12-04 10:41:37 +0100]:
> > Sure.  It's struct *statfs*, not struct *statvfs*.  We also have a
> > statfs system call, not statvfs.  So you're talking about adding a new
> > system call.
> >
> >Sam Steingold wrote:
> >> Any change this might get rectified in the nearest future?
> >
This looked simple, so I thought I would take a stab.

I assume it will be considered non-trivial, even though I think it was.
So, I am trying once again to get a disclaimer from my employer.  I think
it will go through this time.  But, since it is not a company priority, it
may take a while.

> > Any important information you can't get from statfs?  Otherwise it's
> > a matter of time and interest, as usual.
> >
> I cannot get f_frsize, f_flag, and f_favail.
>
> This is also a portability issue.
>
Incidentally, this does not seem to be POSIX per se, but XSI.  RedHat 8,
in fact, does not seem to have such a call.

I believe that (at least for my Cygwin implementation):

statvfs.f_frsize = statvfs.f_bsize = statfs.f_bsize

Since these are meaningless on Cygwin?
statvfs.f_favail ~= statvfs.f_ffree = statfs.f_ffree = (fsfilcnt_t)-1
statvfs.f_files = (fsfilcnt_t)-1

The inode stats are supposed to be of type fsfilcnt_t.  Should that
be unsigned long, or unsigned long long?  It probably just doesn't matter
since we don't support them anyway.

Also, the block stats are supposed to be of type fsblkcnt_t.  I assume
that should be the same as blkcnt_t?

The standard says these should be defined in <sys/types.h>, but FreeBSD
defines them in <sys/statvfs.h>.  Which do you prefer?

Do we continue to use <sys/vfs.h> for struct statvfs and [f]statvfs
prototypes; just making <sys/statvfs.h> a wrapper like <sys/statfs.h>?
Or, do we do away with <sys/vfs.h>, moving its contents to <sys/statfs.h>,
and make a parallel <sys/statvfs.h>?  Obviously, there is a possible third
hybrid permutation here, but that just doesn't seem to be consistent.

The standard says that the statvfs prototype should be:
int statvfs(const char *restrict, struct statvfs *restrict);

What is Cygwin's policy on the restrict key word (don't use, restrict [I
think this is bad for c++], __restrict [FreeBSD, libiberty, linux newlib],
__restrict__ [mingw], etc.)?

statvfs.f_flag = statfs.f_type

These are currently a pass through of the flags obtained from
GetVolumeInformation().  I don't see their meanings defined outside of
winbase.h (and some are not even defined there).  What is the policy here?
We can't really include winbase.h and make dependent defines, can we?  I
assume we just need to make new *nix style defines with hard coded values?
Should they correspond, or should the Cygwin dll translate them?

The statvfs spec requires at least:
ST_RDONLY Read-only file system.
ST_NOSUID Does not support the semantics of the ST_ISUID and ST_ISGID file
mode bits.

Solaris also has:
ST_NOTRUNC Does not truncate file names longer than NAME_MAX
(Although, I don't understand what that means.  It gives an error
instead?)

I'm still digging for how to determine these.  Suggestions are welcome.

Well, I'm sure that's more than enough for now.  Sorry for the huge list
of questions.  I'm still getting my feet wet in accepted Cygwin policy,
coding standards, etc.

PS. I'm still seeing random silent "deaths" with the current cvs
cygwin1.dll.  Long configure scripts randomly stop in the middle.
Re-running them, they might complete, or they might stop in a different
spot.  Even configuring/compiling Cygwin again is then a hit and miss
proposition.  Does anyone else see this or have an idea how to debug it?

Thanks.

-- 
Brian Ford
Senior Realtime Software Engineer
VITAL - Visual Simulation Systems
FlightSafety International
Phone: 314-551-8460
Fax:   314-551-8444