cdrom(4)cdrom(4)NAMEcdrom - CD-ROM background information
This manpage provides general information on existing CD-ROM standards,
terminology, data layout, and levels of support. More detailed infor‐
mation is available in the standard documents listed in
Not all topics discussed here are supported in the current HP-UX
release. Refer to the section for details about the contents of the
Currently, two standard formats are defined for CD-ROM.
The High Sierra Group (HSG) standard was produced by the CD-ROM Ad Hoc
Advisory Committee, and is documented in a publication entitled This
document is available from the National Information Standards Organiza‐
The second standard, which evolved from the HSG standard, was produced
by the International Organization for Standardization (ISO). This
standard is documented in a publication entitled reference number ISO
9660: 1988 (E).
The data layout on a CD-ROM can be represented as follows:
│ System Area - 32 kilobytes │
│ Volume Descriptor │
│ . │
│ . │
│ . │
│ Volume Descriptor Terminator │
│ . │
│ . │
│ . │
│ Path Table │
│ Path Table │
│ . │
│ . │
│ . │
│ Directory and File Data │
│ . │
│ . │
│ . │
There are typically four─sections─in─the─CD-ROM─data (indicated by dou‐
ble horizontal lines in the table above): Only the first two sections
must occur in the order shown above.
The consists of the first sixteen 2048-byte blocks on the media. The
contents of this section are not specified by either standard; here,
the creator of the CD-ROM can put data that is relevant to the system
for which the CD-ROM is intended.
The typically contains one primary volume descriptor and zero or more
supplementary volume descriptors. Each volume descriptor is 2048 bytes
in length, and describes the attributes and structure of a directory
hierarchy on the CD-ROM. The list of volume descriptors is terminated
by one or more A volume descriptor terminator is also 2048 bytes in
length, and simply signals the end of the volume descriptor section.
The contains all the path tables for all directory hierarchies on the
CD-ROM. Path tables do not have to be constrained to this section of
the CD-ROM data, but can be interspersed with (described below) to min‐
imize seek times.
The contains data for all directory hierarchies on the CD-ROM and, as
described above, can be made noncontiguous by the occasional inclusion
of a path table.
Volumes and Directory Hierarchies
A is a single physical CD-ROM. A is a hierarchical file system written
on a volume. Multiple directory hierarchies can be placed on a single
volume, or a single directory hierarchy can span multiple volumes.
Each directory hierarchy on a volume is described by a
Directory hierarchies on the same volume can be totally independent of
each other with each one defining a totally unique and unrelated file
system. They can also be related to each other through the sharing of
data between them.
A is a set of one or more volumes that are to be treated as a unit.
Each successive volume in the volume set updates or augments the data
on the volumes preceding it. Thus, the last volume in a volume set is
always the volume which describes the most up-to-date directory hierar‐
chy for the volume set. A unique and ascending value called the is
assigned to each volume in a volume set. Volume sets are useful for
updating large multivolume databases without having to rework the
Each directory hierarchy on a volume is described by a There are sev‐
eral types of volume descriptors, but the two of most interest are the
and the Their content is almost identical, but they have different
The primary volume descriptor describes the primary directory hierarchy
on a volume. If there are additional directory hierarchies on the vol‐
ume, or different ways to view the same directory hierarchy, these are
described by supplementary volume descriptors. In the case of a volume
set, the primary volume descriptor on each volume describes the primary
directory hierarchy for that volume and all preceding volumes in the
set thus far.
Volume descriptors contain the following information:
standard ID (identifies the format of the volume);
size of the volume;
volume set size;
volume sequence number;
logical block size;
path table size;
pointers to the path tables;
directory record for the root directory;
volume set ID;
data preparer ID;
copyright file name;
abstract file name;
bibliographic file name (ISO only);
volume creation date and time;
volume modification date and time;
volume expiration date and time;
volume effective date and time;
application use area.
A defines a directory hierarchy structure within a volume. Each path
table contains a record for each directory in the hierarchy. In each
record are kept the directory's name, the length of any extended
attribute record associated with the directory, the logical block num‐
ber of the block in which the directory begins, and the number of the
parent directory for that directory. (All directories in a path table
are numbered according to the order in which they appear in the path
There are two types of path tables. One is a path table in which all
numerical values in each path table record are recorded least-signifi‐
cant-byte-first. The other type, is a path table in which all numeri‐
cal values are recorded most-significant-byte-first. One of each type
of path table is required by both standards. The ISO standard allows
for one additional optional copy of each type of path table, while the
HSG standard allows for up to three additional optional copies of each
type. Additional copies of path tables are useful for redundancy or
seek time minimization.
Extended Attribute Records
An (abbreviated ) is a data structure specifying additional information
about the file or directory with which the XAR is associated. An XAR
contains the following information:
creation date and time;
modification date and time;
expiration date and time;
effective date and time;
application use area.
If an XAR is recorded, the XAR is written beginning at the first block
of the file or directory. The actual data for the file or directory is
written beginning at the next block after the block in which the XAR
Where possible, XAR information is mapped into the stat structure by
the system call (see stat(2)). However, many items do not map very
well due to lack of appropriate fields in the stat structure for infor‐
mation provided by the XAR. To preserve backward compatibility of the
stat structure, such information is discarded by The system call can be
used to obtain the XAR for a particular file or directory (see
For performance reasons, data in a file can be interleaved when
recorded on the volume. This is accomplished by dividing the file into
pieces called The size of each file unit (in logical blocks) is called
the The interleaved file is then recorded onto the volume by writing a
file unit, skipping one or more blocks, writing another file unit,
skipping more blocks, and so on until the entire file is recorded. The
number of blocks to skip between file units is called the Blocks making
up the interleave gap are available for assignment to other files.
File unit and interleave gap sizes are kept in the directory record for
each file. Thus, the file unit and interleave gap sizes may change
from file to file, but cannot change within the same file (unless the
file is written in − see below).
Directories cannot be interleaved.
In order to be able to share data between files, a file can be broken
up into File sections for a particular file are not necessarily all the
Each file section is treated like a separate file in that each section
gets its own directory record. This implies that each file section has
its own size, its own XAR, and its own unique file unit and interleave
gap sizes. However, all file sections for the same file must all share
the same file name. The order of the file sections in the file is
determined by the order of the directory records for each section. A
bit in each directory record determines whether or not that record is
the last record for the file.
A file section can appear more than once in a single file, or appear
many times in many different files. A file section in one volume can
also be claimed by a file in a subsequent volume in a volume set (this
is how updates are accomplished).
Each file section can have its own XAR. However, if the final file
section of a file has no associated XAR, the entire file is treated as
if it has no XAR. This is done to make updates work sensibly.
Directories must always consist of a single section.
Implementation and Interchange Levels
CD-ROM standards define two levels of implementation and three levels
of interchange. provide a way for receiving systems that support CD-
ROM to specify their level of support. The implementation levels are:
Level 1 The system is permitted to ignore supplementary vol‐
ume descriptors, their associated path tables, and
all directory and file data associated with them.
Level 2 No restrictions apply.
In all cases, receiving systems must fulfill the receiving system
requirements specified in section 10 of the ISO standard (no equivalent
section exists for HSG).
provide a way to specify the data structure and complexity that exists
on a CD-ROM.
The levels are:
Level 1 Each file consists of a single file section. File
names contain no more than eight characters, and
file name extensions contain no more than three.
Directory names contain no more than eight charac‐
Level 2 Each file consists of a single file section.
Level 3 No restrictions apply.
HP-UX supports only the primary volume descriptor. When a volume is
mounted, HP-UX mounts the directory hierarchy described by the first
primary volume descriptor it finds. Supplementary volume descriptors
are recognized and ignored, as are their associated directory hierar‐
Directory hierarchies spanning multiple volumes are not supported.
Volume sets consisting of more than one volume are not supported.
Path tables are ignored in HP-UX. The normal path name lookup scheme
used in HFS file systems is used instead. This is done to allow other
mountable file systems to be mounted on top of a mounted CDFS file sys‐
tem. Also, since HP-UX maintains a cache of cdnodes for CDFS files
(see cdnode(4)), the additional performance gains provided by path
tables are minimal.
HP-UX does not support multiple file sections. Each file must be
recorded in a single file section.
HP-UX supports level 1 implementation and level 2 interchange.
SEE ALSOfsctl(2), stat(2), cdnode(4).
Ref. No. ISO 9660: 1988 (E).
National Information Standards Organization [Z39].