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.

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:


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:

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


© 2005 The SCO Group, Inc. All rights reserved.
SCO OpenServer Release 6.0.0 -- 03 June 2005