Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!wuarchive!gem.mps.ohio-state.edu!ginosko!uunet!software.org!kint
From: kint@software.org (Rick Kint)
Newsgroups: comp.sys.apollo
Subject: Re: 2 Programming Questions
Summary: use stat() to get file attributes
Message-ID: <431@sunny.software.org>
Date: 18 Oct 89 15:42:35 GMT
References: <8910171131.AA01220@umix.cc.umich.edu>
Sender: usenet@software.org
Reply-To: kint@software.org (Rick Kint)
Organization: Software Productivity Consortium, Herndon, Virginia
Lines: 48

In article <8910171131.AA01220@umix.cc.umich.edu> MARCUS@MOLE.PCL.AC.UK writes:
>
>(ii)  Is there a quick way to get a file's type-uid/size for inclusion in a
>      directory listing? Stream_$inquire takes forever and a day.

       stream_$inquire has the unfortunate characteristic of opening files
first (like the name implies), which means it isn't too useful for getting
attributes for, say, pty files--it hangs.  As anyone who has used Apollos for
any length of time will guess, there is an unreleased call which does exactly
what he seeks...

        There is also a legal way of doing this, using a UNIX call.  The stat
call is used to get information about files.  This uses the "struct stat" data
structure, defined in /usr/include/sys/stat.h.  The size of a file in bytes is
in the member st_size (declared as an off_t, which is a long) and the block
count is in st_blocks (a long).  These are standard UNIX file attributes.  The
type UID is hidden, since it's not standard UNIX.  At SR9.X, the type UID of a
file is contained in the member st_spare4 (declared: long st_spare4[2]) and at
SR10 the type UID is in st_rfu[0] and st_rfu[1] (declared: long st_rfu4[5]).
In both cases the first long (st_spare4[0] and st_rfu[0]) is the high part of
the UID.  This is observed behavior;  it isn't documented in anything that
I've seen, but canned type UIDs are pretty distinctive in hex.

        Three problems arise:  first, this is C, but using stat from another
language shouldn't be too hard;  use the insert files for different languages
in /sys/ins to see how things are mapped between languages.  UNIX calls don't
use the std_$call convention, so you need to make sure that pointers are really
pointers.  Second, if you're at SR9.X and don't have Domain/IX, this
information won't help you.

        The third is a bigger problem.  Inclusion of the type UID in struct
stat is undocumented (and therefore unsupported) behavior:  stat.h at SR10
explicitly states that st_rfu is "reserved to Apollo".  The member containing
the type UID changed from SR9.7 to SR10, and may very well change again.
Programs using this behavior may break in the future.

        This is not a criticism;  Apollo was between Scylla and Charybdis here.
If they were to add a new member st_typeuid to struct stat, someone would use
this as further evidence that SR10 isn't "JLRU" and make much ado over nothing.
Nonetheless, it would be nice to have a dependable, supported way to access
Apollo-specific file attributes.  And if anyone from Apollo is listening:  just
what does the name "rfu" stand for? For some reason, the expression "JLRFU"
comes to mind...

--
Rick Kint                          CSNET:   kint@software.org
Software Productivity Consortium   ARPANET: kint%software.org@relay.cs.net   
Herndon, VA                        UUNET:   ...!uunet!sunny!kint