[I sent this on Friday, but apparently I got unsubscribed from the
list recently and the post didn't make it.  So if you're seeing a
duplicate somehow, that's what's happened, and sorry in advance.]

I've got an application that needs to get statistics from mounted
filesystems.  The obvious way to do this is to use the Unix system
calls getfsstat(2) and/or statfs(2) -- both of which appeared for the
first time in 4.4BSD, maybe after the UNIX package was implemented.

I did some poking around, and it looks like Solaris and FreeBSD have
some pretty significantly different approaches to dealing with this
kind of information.  They both have the system calls needed to get at
the stuff, but they're not the same.  In any case, it doesn't seem
that CMUCL has the calls implemented in the UNIX package either way.

Using RUN-PROGRAM to ask df(1) interests me only slightly more than
poking myself in the eye.

Am I missing something that gives me what I need?  I see all of the
other filesystem calls like stat(2), access(2), and friends, but this
doesn't help much when I need the program to see how much total space
a filesystem has and how much is available.

It looks to me like CMUCL doesn't provide the access to the data I
need right now and that the Right Solution is to implement the
filesystem calls needed.  Initially, I'd think they should be in the
UNIX package, but since that will vary between BSD and System V
variants, this could create a situation where Lisp code that talks to
the filesystem would need not just to check for CMU but also which
Unix it's on, which seems silly.  Maybe something should be
implemented in EXTENSIONS to provide a consistent interface to
filesystem metadata, so at least the Lisp code that talks to the
filesystem can be consistent across Unices.

Is this correct?  Has anyone else dealt with this?

-- 
Matt Curtin, CISSP, IAM, INTP.  Keywords: Lisp, Unix, Internet, INFOSEC.
Founder, Interhack Corporation +1 614 545 HACK http://web.interhack.com/
Author of /Developing Trust: Online Privacy and Security/ (Apress, 2001)

Reply via email to