AIX 3.1 directories (was Re: AIX LPR OPTIONS (?))

[John R. Miller]

In article <1990Oct2.163654.797 at panews> jsalter at slo.UUCP (Jim Salter) writes:
>In article <390 at ulticorp.UUCP> rick at ulticorp.UUCP (rick/1024000) writes:
>>AIX is NOTTTTT System 5!!!!!!
>
>Yes, nor is it 4.3 BSD.  Nor any other flavor of Unix, though it does a
>decent job merging at least 4.3 BSD and System 5.
>
>>The directory structure is very interesting.
>
>The directory structure is certainly not the base to test whether a
>Unix-derivative is System 5 or not.  In fact, the filesystem is the
>Journalling/Journalled File System (JFS) which does a good job of being
>different all by itself.

True enough, but the journaling is independent of the directory
structure.  Anyway, in this thread, what was meant when the original
poster said something like "AIX is System V" was "AIX has 14 character
filenames" as they were offering an explanation for problems with spool
files that had long names.

>>The directory structure is very interesting.
>>For example, try executing
>>the following commands on an RS/6000.
>>	echo > This_is_a_long_filename 
>>	ls This*
>>	od -c .
>>The output from 'ls' shows the long name, but the output from 'od' shows only
>>14 characters.
>
>Yes, I know.  I opened a problem report about this a long time ago before
>GA.  The reason this happens is that only the first 14 characters of a
>filename are stored in the directory with a pointer off to the rest.  Since
>od just reads the parameter you give it, and won't spend it's time tracing
>pointers, the output you get from od is valid, it just *looks* System 5-ish.

I don't think this is correct.  In particular, I don't think there is
anything special about the first 14 characters of a filename in the way
it's stored in a directory in AIX 3.1, and I don't think there are any
pointers involved.  I don't have an S/6000 or a pure 4.3BSD machine
handy to check this on, but I wouldn't be surprised to find that the
layout of the directories is similar.

In any case, the fault isn't with od failing to trace anything; all it's
doing is calling read(2).  What read delivers depends on the value of
the PROC_RAWDIR bit in the u_compatibility field of the u-block (look in
user.h)  This can be changed by calling ulimit(2) with SET_REALDIR --
look under ulimit in info for the details.  The current state can be
queried via ulimit with GET_REALDIR.  (Don't place large sums of money
on the accuracy of the field names, etc. as I'm doing this from memory. 
They're close, however.)

The upshot is that read, by default, processes the output it delivers in
a way that makes it look like a so-called SysV directory (i.e., 14
characters, not necessarily NUL terminated) when it is reading a
directory.  As noted above, this is just the default behavior.  It can
be changed via ulimit.  I suspect the reasoning was that an application
that attempts to do a straightforward read of a directory probably is
only prepared to handle the equally straightforward V7 format.  On the
other hand, an application that realizes it might be running on a BSD
system, will probably use readdir(2).  This way, both work, but an
unfortunate side effect is that the output of od . is somewhat
misleading.

disclaimer:  Not to be confused with my employer.
-- 
John R. Miller							  512/331-0155
13102 Briar Hollow Dr.					john at crcaus.cactus.org
Austin, Texas  78729			   ...cs.utexas.edu!bigtex!crcaus!john