hierarchy -- layout of filesystem


The following information describes the filesystem hierarchy:

root of filesystem

traditional export location for public executable programs

export location for XPG4-specific versions of public executable programs

root of directory hierarchy for block and character device special files

traditional export location for public system administration programs and files

export location for components of the Link Kit hierarchy

export location for Link Kit utilities; see idinstall(ADM)

export location for Link Kit configuration files

location of entries to be added to inittab(F)

location of descriptions of device special files to be added to /dev

location of device driver files such as Driver.o, space.c, and stubs.c

location of kernel object modules and stub files

export location for sdevice(F) entries

export location for utility configuration files

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)

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

export location for binaries needed to install the system

files located by fsck

mount point for filesystems mounted temporarily

mounted network directories; see automount(NADM)

root of directory hierarchy for shared read-only data

root of directory hierarchy for read-only software storage objects (SSOs) that can be shared by several client machines

SSO component root containing public (exported) and private read-only files

root of directory hierarchy for product database information

export location for public static shared libraries

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

storage for trusted computing base

temporary storage, periodically purged

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

alternative name for /home

traditional export location for public user hierarchy

traditional export location for public executable programs

traditional export location for public program header files

traditional export location for static and dynamic shared libraries

traditional export location for delayed execution files used by system services such as cron, printing, and mail

temporary storage, periodically purged

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

root of directory hierarchy for writable system data such as configuration information

root of directory hierarchy for the non-shared (client-specific) writable portions of component SSOs

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.

Once configured to a particular client, an SSO has two parts: 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:

Files remain under /opt. They are not linked to an external directory.

Files are copied to /var/opt for each client. They are not linked to an external directory.

Files remain in /opt and are linked to an external directory.

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:


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:


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
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.


Note the following when making changes to files within SSOs:

See also

automount(NADM), boot(HW), cd(C), csh(C), custom(ADM), idinstall(ADM), init(M), inittab(F), ksh(C), pwd(C), sdevice(F), sh(C), ssoPathMap(ADM)

Standards conformance

hierarchy is conformant with:

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

© 2003 Caldera International, Inc. All rights reserved.
SCO OpenServer Release 5.0.7 -- 11 February 2003