Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!execu!sequoia!balkan!crcaus!john From: john@crcaus.cactus.org (John R. Miller) Newsgroups: comp.unix.aix Subject: AIX 3.1 directories (was Re: AIX LPR OPTIONS (?)) Summary: by default read(2) converts Message-ID: <293@crcaus.cactus.org> Date: 4 Oct 90 06:21:21 GMT References: <1990Oct1.223701.25867@ux1.cso.uiuc.edu> <1990Oct1.232359.4332@ux1.cso.uiuc.edu> <390@ulticorp.UUCP> <1990Oct2.163654.797@panews> Reply-To: john@crcaus.cactus org (John R. Miller) Organization: home Lines: 68 In article <1990Oct2.163654.797@panews> jsalter@slo.UUCP (Jim Salter) writes: >In article <390@ulticorp.UUCP> rick@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@crcaus.cactus.org Austin, Texas 78729 ...cs.utexas.edu!bigtex!crcaus!john