hierarchy(M)

hierarchy -- layout of filesystem

Description

The following information describes the filesystem hierarchy:

/

root of filesystem

/bin/

traditional export location for public executable programs

posix: export location for XPG4-specific versions of public executable programs

/dev

root of directory hierarchy for block and character device special files

/etc/

traditional export location for public system administration programs and files

conf: export location for components of the Link Kit hierarchy
conf/bin: export location for Link Kit utilities; see idinstall(ADM)
conf/cf.d: export location for Link Kit configuration files
conf/init.d: location of entries to be added to inittab(F)
conf/node.d: location of descriptions of device special files to be added to /dev
conf/pack.d/driver: location of device driver files such as Driver.o, space.c, and stubs.c
conf/pack.d/kernel: location of kernel object modules and stub files
conf/sdevice.d: export location for sdevice(F) entries
default: export location for utility configuration files
rc.d: export location for scripts run automatically at system startup and shutdown; obsolete, exists for XENIX compatibility
rc0.d, rc2.d, rc3.d, shutdown.d: export location for scripts run automatically at system startup and shutdown; see init(M)

/home

conventional name for second filesystem which contains users' home directories; may be mounted from a central server; some system administrators may choose to set this up as /u

/ibin

export location for binaries needed to install the system

/lost+found

files located by fsck

/mnt

mount point for filesystems mounted temporarily

/net

mounted network directories; see automount(NADM)

/opt/

root of directory hierarchy for shared read-only data

K: root of directory hierarchy for read-only software storage objects (SSOs) that can be shared by several client machines
K/VendorCode/ComponentCode/ComponentVersion: SSO component root containing public (exported) and private read-only files
P: root of directory hierarchy for product database information

/shlib

export location for public static shared libraries

/stand

the boot filesystem, which typically contains the /boot executable, boot standalone programs, and bootable kernels; see boot(HW)

/tcb

storage for trusted computing base

/tmp

temporary storage, periodically purged

/tmp_mnt

default storage for temporary mount points used by the automounter; see automount(NADM)

/u

alternative name for /home

/usr/

traditional export location for public user hierarchy

bin: traditional export location for public executable programs
include: traditional export location for public program header files
lib: traditional export location for static and dynamic shared libraries
spool: traditional export location for delayed execution files used by system services such as cron, printing, and mail
tmp: temporary storage, periodically purged

/var/

root of directory hierarchy for non-shared (client-specific) data

opt: root of directory hierarchy for writable system data such as configuration information
opt/K: root of directory hierarchy for the non-shared (client-specific) writable portions of component SSOs
opt/K/VendorCode/ComponentCode/ComponentVersion: root of directory hierarchy containing copies of public (exported) and private writable files belonging to a component's SSO

Software storage objects (SSOs)

An SSO starts out as a single directory subtree in the /opt hierarchy. The pristine state of the SSO remains in the same location throughout its lifetime on the system, and can be used as a clean source for network installations later. Each time a software storage object is configured to a particular client, it expands by copying some files and creating links to other files. Some files are both copied and linked. (Throughout this discussion, client refers to either the local system or a network filesystem client such as a diskless machine.)

How a file is accessed after its SSO is configured to a client depends on whether the file is shared or non-shared, and whether it is public or private.

A shared file is one that a client reads, but does not modify. If a file is shared among multiple client machines on the network, it exists only in the original distribution location (/opt).
A non-shared file is specific to an individual client. The client can modify this file without affecting any other client's copy. During the ``attach'' phase of installation, non-shared files are copied from a private directory under the SSO's /opt hierarchy to the appropriate /var/opt subdirectory.
A public file is one that is visible and accessible outside of a component's private SSO. This lets users and outside components access the file by means of symbolic links.
A private file is one that is not visible outside of a component's SSO. Only programs and scripts belonging to the component are expected to access a private file directly, so accessing a private file from outside the SSO is not supported. Files such as back-end binaries, data files, and internal configuration files may be private files.

Once configured to a particular client, an SSO has two parts:

a /opt part which is shared
a /var/opt part which is specific to a client

These two parts can be called the program part (/opt) and the data part (/var/opt). This separation between program and data allows control over the location of data that must be backed up regularly or preserved during an upgrade. For each SSO in a product, a client can locate the program part locally or remotely, and the data part locally or remotely. Also, the remote part of each storage object can be located on a different server.

Once an SSO is configured into a /opt part and a /var/opt part, the ``export'' phase of installation makes public those read-only and writable files which are not private to the SSO. Symbolic links are created from the traditional file locations to real files in the /opt and /var/opt hierarchies. The symbolic links allow every public file's true location to be made transparent to the system. See ``Hiding the details of SSO implementation'' for more information.

Both shared and non-shared files may be either private or public. There is no mutual exclusivity between these attributes. The following four combinations are possible:

shared/private: Files remain under /opt. They are not linked to an external directory.
non-shared/private: Files are copied to /var/opt for each client. They are not linked to an external directory.
shared/public: Files remain in /opt and are linked to an external directory.
non-shared/public: Files are copied to /var/opt for each client and are linked to an external directory.

Product file locations

The files in an SSO are stored in the subtree located under the directory:

/opt/K/VendorCode/ComponentCode/ComponentVersion

This directory is called a component's SSO root. For example, the SSO root for the SCO OpenServer X server component, version 5.2.0d, is /opt/K/SCO/XServer/5.2.0d.

Corresponding to the SSO itself is a directory in /var in the client's local file space. This is the hierarchy to which all non-shared files are copied. The pathname to the directory in /var is:

/var/opt/K/VendorCode/ComponentCode/ComponentVersion

Link Kit hierarchy

The Link Kit hierarchy contains the utilities, source and object files that your system needs to create a new version of the kernel. Rebuilding the kernel is necessary when configuration changes are made such as changing the value of a kernel parameter, or adding a new device driver.

Many files and some directories in the Link Kit are symbolic links into the Unix component SSO. This can produce some unexpected effects if you use relative pathnames to access different parts of the Link Kit. See ``Hiding the details of SSO implementation'' for more information.

If you are writing shell scripts, you can use ssoPathMap(ADM) to return the path to the root of an SSO.

Other Link Kit files under /var/opt are symbolic links to the Unix component SSO under /opt. Such files include utilities in /etc/conf/cf.d, most Driver.o and stubs.c files under /etc/conf/pack.d/*, kernel object files in /etc/conf/pack.d/kernel, and some driver configuration scripts. These files are shared/read-only and should not normally be modified.

If you need to make a temporary copy of the Link Kit for test purposes, use the command cpio -pLd. This will replace symbolic links with real files in the copy. (Do not use the tar(C) command as its inherent limitations make it unsuitable for making a copy of the Link Kit.) Copy the Link Kit to a temporary directory hierarchy, and then set and export the environment variable ROOT so that the Link Kit utilities will work with the directory hierarchy having /tmp/new_root as its root. For example, the following commands create a copy of the Link Kit under /tmp/new_root/etc/conf:

find /etc/conf -follow -print | cpio -pLd /tmp/new_root
ROOT=/tmp/new_root
export ROOT

Hiding the details of SSO implementation

Software storage objects (SSOs) preserve the traditional directory structure and filenames by using symbolic links to point to the real files which are maintained in the /var and /opt/var directory hierarchies.

The versions of the cd(C) and pwd(C) commands built into the Bourne, and C shells use physical pathnames by default. Use the -L option to cd to traverse the traditional directory structure while hiding the details of the implementation of SSOs. Similarly, the -L option to pwd displays the traditional directory structure. The default behavior of these shells can be changed to use logical pathnames by specifying the -L option to sh(C), or by setting the cdlogical variable for csh(C).

The versions of cd and pwd built into the Korn shell and /bin/posix/sh (the XPG4-compliant version of ksh(C)) use logical pathnames (assume the -L option) by default.

The /bin/cd and /bin/pwd utilities only understand physical pathnames.

The -l option to ls(C) displays symbolic links and the files to which they point. However, this lists the details of the symbolic link's inode rather than the inode details of the file to which it points. When listing files, use the l(C) command or the -Ws option to ls to hide the implementation of SSOs. If a file is a symbolic link, an ``@'' is appended to its filename and the inode details of the file ultimately pointed to are displayed. Specify the -Wv option if you want to display all filenames in a chain of symbolic links.

Warning

Note the following when making changes to files within SSOs:

If a file is not exported out of the SSO, it is private to the component and may or may not be included in future releases of the product. It is not a public file. In general, you should not access these files from your own scripts or programs.
Any modification that you make to a file under the /opt/K/VendorCode/ComponentCode/ComponentVersion hierarchy affects more than just the local host. The change will be carried along by custom to any other machines installed from the changed host, and it will also affect diskless and dataless clients of this machine. Make changes to such files with caution. You can detect such changes using the custom verification function (for more information, see custom(ADM)).
Changing directories using relative pathnames (especially from within scripts) may not always place you in the directory you expect.

Standards conformance

hierarchy is conformant with:

Intel iBCS, Specification 2 (iBCS2), 1991;
AT&T SVID, Third Edition (SVID 3), 1989