ISO 9660
ISO 9660
Main page
2322547

ISO 9660

logo
Community Hub0 subscribers
Read side by side
ISO 9660
View on Wikipedia
from Wikipedia

ISO 9660
Developer(s)ISO/IEC, Ecma International
VariantsISO 13490
Introduced1988; 37 years ago (1988)
Limits
Max volume size8 TiB (nearly 8.8 TB)
Other
Supported
operating systems		Cross platform
Optical discs
General
Optical media types
Standards
See also

ISO 9660 (also known as ECMA-119) is a file system for optical disc media. The file system is an international standard available from the International Organization for Standardization (ISO). Since the specification is publicly available, implementations have been written for many operating systems.[1]

ISO 9660 traces its roots to the High Sierra Format,[2] which arranged file information in a dense, sequential layout to minimize nonsequential access by using a hierarchical (eight levels of directories deep) tree file system arrangement, similar to Unix file systems and FAT. To facilitate cross platform compatibility, it defined a minimal set of common file attributes (directory or ordinary file and time of recording) and name attributes (name, extension, and version), and used a separate system use area where future optional extensions for each file may be specified. High Sierra was adopted in December 1986 (with changes) as an international standard by Ecma International as ECMA-119[3] and submitted for fast tracking to the ISO, where it was eventually accepted as ISO 9660:1988.[4] Subsequent amendments to the standard were published in 2013, 2017, 2019, and 2020.

The first 16 sectors of the file system are empty and reserved for other uses. The rest begins with a volume descriptor set (a header block which describes the subsequent layout) and then the path tables, directories and files on the disc. An ISO 9660 compliant disc must contain at least one primary volume descriptor describing the file system and a volume descriptor set terminator which is a volume descriptor that marks the end of the descriptor set. The primary volume descriptor provides information about the volume, characteristics and metadata, including a root directory record that indicates in which sector the root directory is located. Other fields contain metadata such as the volume's name and creator, along with the size and number of logical blocks used by the file system. Path tables summarize the directory structure of the relevant directory hierarchy. For each directory in the image, the path table provides the directory identifier, the location of the extent in which the directory is recorded, the length of any extended attributes associated with the directory, and the index of its parent directory path table entry.

There are several extensions to ISO 9660 that relax some of its limitations. Notable examples include Rock Ridge (Unix-style permissions and longer names), Joliet (Unicode, allowing non-Latin scripts to be used), El Torito (enables CDs to be bootable) and the Apple ISO 9660 Extensions (file characteristics specific to the classic Mac OS and macOS, such as resource forks, file backup date and more).

History

[edit]

Compact discs were originally developed for recording musical data, but soon were used for storing additional digital data types because they were equally effective for archival mass data storage. Called CD-ROMs, the lowest level format for these types of compact discs was defined in the Yellow Book specification in 1983. However, this book did not define any format for organizing data on CD-ROMs into logical units such as files, which led to every CD-ROM maker creating its own format. In order to develop a CD-ROM file system standard (Z39.60 - Volume and File Structure of CDROM for Information Interchange), the National Information Standards Organization (NISO) set up Standards Committee SC EE (Compact Disc Data Format) in July 1985.[5] In September/[6] October 1985 several companies invited experts to participate in the development of a working paper for such a standard.

In November 1985, representatives of computer hardware manufacturers gathered at the High Sierra Hotel and Casino (currently called the Golden Nugget Lake Tahoe) in Stateline, Nevada.[7] This group became known as the High Sierra Group (HSG). Present at the meeting were representatives from Apple Computer, AT&T,[citation needed] Digital Equipment Corporation (DEC), Hitachi, LaserData, Microware,[citation needed] Microsoft, 3M, Philips, Reference Technology Inc., Sony Corporation, TMS Inc., VideoTools (later Meridian[8]), Xebec, and Yelick.[citation needed] The meeting report evolved from the Yellow Book CD-ROM standard, which was so open ended it was leading to diversification and creation of many incompatible data storage methods. The High Sierra Group Proposal (HSGP) was released in May 1986, defining a file system for CD-ROMs commonly known as the High Sierra Format.

A draft version of this proposal was submitted to the European Computer Manufacturers Association (ECMA) for standardization. With some changes, this led to the issue of the initial edition of the ECMA-119 standard in December 1986.[9] The ECMA submitted their standard to the International Standards Organization (ISO) for fast tracking, where it was further refined into the ISO 9660 standard. For compatibility the second edition of ECMA-119 was revised to be equivalent to ISO 9660 in December 1987.[10][11][12] ISO 9660:1988 was published in 1988. The main changes from the High Sierra Format in the ECMA-119 and ISO 9660 standards were international extensions to allow the format to work better on non-US markets.

In order not to create incompatibilities, NISO suspended further work on Z39.60, which had been adopted by NISO members on 28 May 1987. It was withdrawn before final approval, in favour of ISO 9660.[5]

JIS X 0606:1998 was passed in Japan in 1998 with much-relaxed file name rules using a new "enhanced volume descriptor" data structure. The standard was submitted for ISO 9660:1999 and supposedly fast-tracked, but nothing came out of it.[13] Nevertheless, several operating systems and disc authoring tools (such as Nero Burning ROM, mkisofs and ImgBurn) now support the addition, under such names as "ISO 9660:1999", "ISO 9660 v2", or "ISO 9660 Level 4". In 2013, the proposal was finally formalized in the form of ISO 9660/Amendment 1, intended to "bring harmonization between ISO 9660 and widely used 'Joliet Specification'."[14] In December 2017, a 3rd Edition of ECMA-119 was published that is technically identical with ISO 9660, Amendment 1.[15]

In 2019, ECMA published a 4th version of ECMA-119, integrating the Joliet text as "Annex C".[1]

In 2020, ISO published Amendment 2, which adds some minor clarifying matter, but does not add or correct any technical information of the standard.[16]

Specifications

[edit]

The following is the rough overall structure of the ISO 9660 file system.

Multi-byte values can be stored in three different formats: little-endian, big-endian, and in a concatenation of both types in what the specification calls "both-byte" order. Both-byte order is required in several fields in the volume descriptors and directory records, while path tables can be either little-endian or big-endian.[17]

Top level

[edit]
ISO 9660 file system
System area (32,768 B) Unused by ISO 9660
Data area
Volume descriptor set
Path tables, directories and files

The system area, the first 32,768 data bytes of the disc (16 sectors of 2,048 bytes each), is unused by ISO 9660 and therefore available for other uses.[17] While it is suggested that they are reserved for use by bootable media,[18] a CD-ROM may contain an alternative file system descriptor in this area, and it is often used by hybrid CDs to offer classic Mac OS-specific and macOS-specific content.[citation needed]

Volume descriptor set

[edit]

The data area begins with the volume descriptor set, a set of one or more volume descriptors terminated with a volume descriptor set terminator. These collectively act as a header for the data area, describing its content (similar to the BIOS parameter block used by FAT, HPFS and NTFS formatted disks).

Volume descriptor set
Volume descriptor #1
...
Volume descriptor #N
Volume descriptor set terminator

Each volume descriptor is 2048 bytes in size, fitting perfectly into a single Mode 1 or Mode 2 Form 1 sector. They have the following structure:

Volume descriptor (2,048 bytes)
Part Type Identifier Version Data
Size 1 byte 5 bytes (always 'CD001') 1 byte (always 0x01) 2,041 bytes

The data field of a volume descriptor may be subdivided into several fields, with the exact content depending on the type. Redundant copies of each volume descriptor can also be included in case the first copy of the descriptor becomes corrupt.

Standard volume descriptor types are the following:

Basic volume descriptor types
Value Type
0 Boot record volume descriptor
1 Primary volume descriptor
2 Supplementary volume descriptor, or enhanced volume descriptor
3 Volume partition descriptor
255 Volume descriptor set terminator

An ISO 9660 compliant disc must contain at least one primary volume descriptor describing the file system and a volume descriptor set terminator for indicating the end of the descriptor sequence. The volume descriptor set terminator is simply a particular type of volume descriptor with the purpose of marking the end of this set of structures. The primary volume descriptor provides information about the volume, characteristics and metadata, including a root directory record that indicates in which sector the root directory is located. Other fields contain the description or name of the volume, and information about who created it and with which application. The size of the logical blocks which the file system uses to segment the volume is also stored in a field inside the primary volume descriptor, as well as the amount of space occupied by the volume (measured in number of logical blocks).

In addition to the primary volume descriptor(s), supplementary volume descriptors or enhanced volume descriptors may be present.

  • Supplementary volume descriptors describe the same volume as the primary volume descriptor does, and are normally used for providing additional code page support when the standard code tables are insufficient. The standard specifies that ISO 2022 is used for managing code sets that are wider than 8 bytes, and that ISO 2375 escape sequences are used to identify each particular code page used. Consequently, ISO 9660 supports international single-byte and multi-byte character sets, provided they fit into the framework of the referenced standards. However, ISO 9660 does not specify any code pages that are guaranteed to be supported: all use of code tables other than those defined in the standard itself are subject to agreement between the originator and the recipient of the volume.
  • Enhanced volume descriptors were introduced in ISO 9660, Amendment 1. They relax some of the requirements of the other volume descriptors and the directory records referenced by them: for example, the directory depth can exceed eight, file identifiers need not contain '.' or file version number, the length of a file and directory identifier is maximized to 207.

Path tables

[edit]

Path tables summarize the directory structure of the relevant directory hierarchy. For each directory in the image, the path table provides the directory identifier, the location of the extent in which the directory is recorded, the length of any extended attributes associated with the directory, and the index of its parent directory path table entry. The parent directory number is a 16-bit number, limiting its range from 1 to 65,535.[19]

Directories and files

[edit]
Overview of the ISO 9660 directory structure

Directory entries are stored following the location of the root directory entry, where evaluation of filenames is begun. Both directories and files are stored as extents, which are sequential series of sectors. Files and directories are differentiated only by a file attribute that indicates its nature (similar to Unix). The attributes of a file are stored in the directory entry that describes the file, and optionally in the extended attribute record. To locate a file, the directory names in the file's path can be checked sequentially, going to the location of each directory to obtain the location of the subsequent subdirectory. However, a file can also be located through the path table provided by the file system. This path table stores information about each directory, its parent, and its location on disc. Since the path table is stored in a contiguous region, it can be searched much faster than jumping to the particular locations of each directory in the file's path, thus reducing seek time.

The standard specifies three nested levels of interchange (paraphrased from section 10):

  • Level 1: File names are limited to eight characters with a three-character extension. Directory names are limited to eight characters. Files may contain one single file section.
  • Level 2: File Name + '.' + File Name extension or Directory Name may not exceed 31 characters in length (sections 7.5 and 7.6). Files may contain one single file section.
  • Level 3: No additional restrictions than those stipulated in the main body of the standard. Files are also allowed to consist of multiple non-contiguous sections (with some restrictions as to order).

Additional restrictions in the body of the standard: The depth of the directory hierarchy must not exceed 8 (root directory being at level 1), and the path length of any file must not exceed 255. (section 6.8.2.1).

The standard also specifies the following name restrictions (sections 7.5 and 7.6):[4]

  • All levels restrict file names in the mandatory file hierarchy to upper case letters, digits, underscores ("_"), and a dot. (See also section 7.4.4 and Annex A.)
  • If no characters are specified for the File Name then the File Name Extension shall consist of at least one character.
  • If no characters are specified for the File Name Extension then the File Name shall consist of at least one character.
  • File names shall not have more than one dot.
  • Directory names shall not use dots at all.

A CD-ROM producer may choose one of the lower Levels of Interchange specified in chapter 10 of the standard, and further restrict file name length from 30 characters to only 8+3 in file identifiers, and 8 in directory identifiers in order to promote interchangeability with implementations that do not implement the full standard.[citation needed]

All numbers in ISO 9660 file systems except the single byte value used for the GMT offset are unsigned numbers. As the length of a file's extent on disc is stored in a 32 bit value,[20] it allows for a maximum length of just over 4.2 GB (more precisely, one byte less than 4 GiB). It is possible to circumvent this limitation by using the multi-extent (fragmentation) feature of ISO 9660 Level 3 to create ISO 9660 file systems and single files up to 8 TB. With this, files larger than 4 GiB can be split up into multiple extents (sequential series of sectors), each not exceeding the 4 GiB limit. For example, the free software such as InfraRecorder, ImgBurn and mkisofs as well as Roxio Toast are able to create ISO 9660 file systems that use multi-extent files to store files larger than 4 GiB on appropriate media such as recordable DVDs.[citation needed] Linux supports multiple extents.[21]

Since amendment 1 (or ECMA-119 3rd edition, or "JIS X 0606:1998 / ISO 9660:1999"), a much wider variety of file trees can be expressed by the EVD system. There is no longer any character limit (even 8-bit characters are allowed), nor any depth limit or path length limit. There still is a limit on name length, at 207. The character set is no longer enforced, so both sides of the disc interchange need to agree via a different channel.[15]

Volume size

[edit]

An ISO 9660 volume can be up to 8 tebibytes (nearly 8.8 terabytes) in size, owing to the 32-bit sector count for the volume size, and its allocation unit size which spans 2048 bytes, matching a logical sector on optical discs. The highest number representable in a 32-bit field is 232-1, limiting the volume size to (232-1)×2048 bytes. "Logical" means it is the sector size exposed to the operating system, not necessarily the physical sector size on a disc. DVD and Blu-ray discs have maintained the logical sector size of the CD-ROM, 2048 bytes, to try to maintain reading compatibility with computers and software predating them.

Extensions and improvements

[edit]

There are several extensions to ISO 9660 that relax some of its limitations. Notable examples include Rock Ridge (Unix-style permissions and longer names), Joliet (Unicode, allowing non-Latin scripts to be used), El Torito (enables CDs to be bootable) and the Apple ISO 9660 Extensions (file characteristics specific to the classic Mac OS and macOS, such as resource forks, file backup date and more).

SUSP

[edit]

System Use Sharing Protocol (SUSP, IEEE P1281) provides a generic way of including additional properties for any directory entry reachable from the primary volume descriptor (PVD). In an ISO 9660 volume, every directory entry has an optional system use area whose contents are undefined and left to be interpreted by the system. SUSP defines a method to subdivide that area into multiple system use fields, each identified by a two-character signature tag. The idea behind SUSP was that it would enable any number of independent extensions to ISO 9660 to be created and included on a volume without conflicting. It also allows for the inclusion of property data that would otherwise be too large to fit within the limits of the system use area.

SUSP defines several common tags and system use fields:

  • CE: Continuation area
  • PD: Padding field
  • SP: System use sharing protocol indicator
  • ST: System use sharing protocol terminator
  • ER: Extensions reference
  • ES: Extension selector

Other known SUSP fields include:

  • AA: Apple extension, preferred
  • BA: Apple extension, old (length attribute is missing)
  • AS: Amiga file properties
  • ZF: zisofs compressed file, usually produced by program mkzftree or by libisofs. Transparently decompressed by Linux kernel if built with CONFIG_ZISOFS.[22]
  • AL: records Extended File Attributes, including ACLs. Proposed by libburnia, supported by libisofs.[23]

The Apple extensions do not technically follow the SUSP standard; however the basic structure of the AA and AB fields defined by Apple are forward compatible with SUSP; so that, with care, a volume can use both Apple extensions as well as RRIP extensions.

Rock Ridge

[edit]
"Rock Ridge" redirects here. For the fictional Western town, see Blazing Saddles.

The Rock Ridge Interchange Protocol (RRIP, IEEE P1282) is an extension which adds POSIX file system semantics. The availability of these extension properties allows for better integration with Unix and Unix-like operating systems.[24] The standard takes its name from the fictional town Rock Ridge in Mel Brooks' film Blazing Saddles.[25] The RRIP extensions are, briefly:

The RRIP extensions are built upon SUSP, defining additional tags for support of POSIX semantics, along with the format and meaning of the corresponding system use fields:

  • RR: Rock Ridge extensions in-use indicator (note: dropped from standard after version 1.09)
  • PX: POSIX file attributes
  • PN: POSIX device numbers
  • SL: symbolic link
  • NM: alternate name
  • CL: child link
  • PL: parent link
  • RE: relocated directory
  • TF: time stamp
  • SF: sparse file data

Amiga Rock Ridge is similar to RRIP, except it provides additional properties used by AmigaOS. It too is built on the SUSP standard by defining an "AS"-tagged system use field. Thus both Amiga Rock Ridge and the POSIX RRIP may be used simultaneously on the same volume. Some of the specific properties supported by this extension are the additional Amiga-bits for files. There is support for attribute "P" that stands for "pure" bit (indicating re-entrant command) and attribute "S" for script bit (indicating batch file). This includes the protection flags plus an optional comment field. These extensions were introduced by Angela Schmidt with the help of Andrew Young, the primary author of the Rock Ridge Interchange Protocol and System Use Sharing Protocol. The first publicly available software to master a CD-ROM with Amiga extensions was MakeCD, an Amiga software which Angela Schmidt developed together with Patrick Ohly.[26]

El Torito

[edit]

El Torito is an extension designed to allow booting a computer from a CD-ROM. It was announced in November 1994[27] and first issued in January 1995 as a joint proposal by IBM and BIOS manufacturer Phoenix Technologies. According to legend, the El Torito CD/DVD extension to ISO 9660 got its name because its design originated in an El Torito restaurant in Irvine, California (33°41′05″N 117°51′09″W / 33.684722°N 117.852547°W / 33.684722; -117.852547).[28] The initial two authors were Curtis Stevens, of Phoenix Technologies, and Stan Merkin, of IBM.[28]

A 32-bit PC BIOS will search for boot code on an ISO 9660 CD-ROM. The standard allows for booting in two different modes. Either in hard disk emulation when the boot information can be accessed directly from the CD media, or in floppy emulation mode where the boot information is stored in an image file of a floppy disk, which is loaded from the CD and then behaves as a virtual floppy disk. This is useful for computers that were designed to boot only from a floppy drive. For modern computers the "no emulation" mode is generally the more reliable method. The BIOS will assign a BIOS drive number to the CD drive. The drive number (for INT 13H) assigned is any of 80hex (hard disk emulation), 00hex (floppy disk emulation) or an arbitrary number if the BIOS should not provide emulation. Emulation is useful for booting older operating systems from a CD, by making it appear to them as if they were booted from a hard or floppy disk.[29]

UEFI systems also accept El Torito records, as platform 0xEF. The record is expected to be a disk image containing a FAT filesystem, the filesystem being an EFI System Partition containing the usual \EFI directory. The image should be marked for "no emulation", though it does not actually work like the BIOS "no emulation" mode, in which the BIOS would load the image in memory and execute the code from there.[30]

El Torito can also be used to produce CDs which can boot up Linux operating systems, by including the GRUB bootloader on the CD and following the Multiboot Specification.[29] While the El Torito spec alludes to a "Mac" platform ID, PowerPC-based Apple Macintosh computers don't use it.[31]

Joliet

[edit]

Joliet is an extension specified and endorsed by Microsoft and has been supported by all versions of its Windows operating system since Windows 95[32] and Windows NT 4.0.[33] Its primary focus is the relaxation of the filename restrictions inherent with full ISO 9660 compliance. Joliet accomplishes this by supplying an additional set of filenames that are encoded in UCS-2BE (UTF-16BE in practice since Windows 2000). These filenames are stored in a special supplementary volume descriptor, that is safely ignored by ISO 9660-compliant software, thus preserving backward compatibility.[32] The specification only allows filenames to be up to 64 Unicode characters in length. However, the documentation for mkisofs states filenames up to 103 characters in length do not appear to cause problems.[34] Microsoft has documented it "can use up to 110 characters."[35] The difference lies in whether CDXA extension space is used.[34]

Joliet allows Unicode characters to be used for all text fields, which includes file names and the volume name. A "Secondary" volume descriptor with type 2 contains the same information as the Primary one (sector 16 offset 40 bytes), but in UCS-2BE in sector 17, offset 40 bytes. As a result of this, the volume name is limited to 16 characters.

Many current PC operating systems are able to read Joliet-formatted media, thus allowing exchange of files between those operating systems even if non-Roman characters are involved (such as Arabic, Japanese or Cyrillic), which was formerly not possible with plain ISO 9660-formatted media. Operating systems which can read Joliet media include:

Romeo

[edit]

Romeo was developed by Adaptec and allows the use of long filenames up to 128 characters, written directly into the primary volume descriptor using the current code page. This format is built around the workings of Windows 9x and Windows NT "CDFS" drivers.[42] When a Windows installation of a different language opens a Romeo disk, the lack of code page indication will cause non-ASCII characters in file names to become Mojibake. For example, "ü" may become "³". A different OS may encounter a similar problem or refuse to recognize these noncompliant names outright.

The same code page problem technically exists in standard ISO 9660, which allows open interpretation of the supplemental and enhanced volume descriptors to any character encoding subject to agreement. However, the primary volume descriptor is guaranteed to be a small subset of ASCII.

Apple extensions

[edit]

Apple Computer authored a set of extensions that add ProDOS or HFS/HFS+ (the primary contemporary file systems for the classic Mac OS) properties to the filesystem. Some of the additional metadata properties include:[43]

  • Date of last backup
  • File type
  • Creator code
  • Flags and data for display
  • Reference to a resource fork

In order to allow non-Macintosh systems to access Macintosh files on CD-ROMs, Apple chose to use an extension of the standard ISO 9660 format. Most of the data, other than the Apple specific metadata, remains visible to operating systems that are able to read ISO 9660.

Other extensions

[edit]

For operating systems which do not support any extensions, a name translation file TRANS.TBL must be used. The TRANS.TBL file is a plain ASCII text file. Each line contains three fields, separated by an arbitrary amount of whitespace:

  • The file type ("F" for file or "D" for directory);
  • The ISO 9660 filename (including the usually hidden ";1" for files); and
  • The extended filename, which may contain spaces.

Most implementations that create TRANS.TBL files put a single space between the file type and ISO 9660 name and some arbitrary number of tabs between the ISO 9660 filename and the extended filename.

Native support for using TRANS.TBL still exists in many ISO 9660 implementations, particularly those related to Unix. However, it has long since been superseded by other extensions, and modern utilities that create ISO 9660 images either cannot create TRANS.TBL files at all, or no longer create them unless explicitly requested by the user. Since a TRANS.TBL file has no special identification other than its name, it can also be created separately and included in the directory before filesystem creation.

The ISO 13490 standard is an extension to the ISO 9660 format that adds support for multiple sessions on a disc. Since ISO 9660 is by design a read-only, pre-mastered file system, all the data has to be written in one go or "session" to the medium. Once written, there is no provision for altering the stored content. ISO 13490 was created to allow adding more files to a writeable disc such as CD-R in multiple sessions.

The ISO 13346/ECMA-167 standard was designed in conjunction to the ISO 13490 standard. This new format addresses most of the shortcomings of ISO 9660, and a subset of it evolved into the Universal Disk Format (UDF), which was adopted for DVDs. The volume descriptor table retains the ISO9660 layout, but the identifier has been updated.[44][45]

Disc images

[edit]

Optical disc images are a common way to electronically transfer the contents of CD-ROMs. They often have the filename extension .iso (.iso9660 is less common, but also in use) and are commonly referred to as "ISOs".[46]

Platforms

[edit]

Most operating systems support reading of ISO 9660 formatted discs, and most new versions support the extensions such as Rock Ridge and Joliet. Operating systems that do not support the extensions usually show the basic (non-extended) features of a plain ISO 9660 disc.

Operating systems that support ISO 9660 and its extensions include the following:

See also

[edit]

References

[edit]

Further reading

[edit]
[edit]
Revisions and contributorsEdit on WikipediaRead on Wikipedia

ISO 9660

View on Grokipedia
from Grokipedia
ISO 9660 is an international standard that specifies the volume and file structure of compact disc read-only memory (CD-ROM) for the interchange of information between users of information processing systems.[1] It defines key elements such as volume attributes, file placement, directory hierarchies, and data recording modes to ensure compatibility across diverse systems.[2] Originally developed from the High Sierra format proposed in 1986, ISO 9660 was first published by the International Organization for Standardization in 1988 as ISO 9660:1988, with technical equivalence to ECMA-119 in its second edition.[3] The standard has evolved through amendments and revisions, including Amendment 1 in 2013 for enhanced compatibility and the fourth edition of ECMA-119 in June 2019, which introduced an Enhanced Volume Descriptor to support deeper directory hierarchies and longer file names up to 207 characters.[4] A further update, ISO/IEC 9660:2023, refines the specifications for volume and file structures, including record formats.[5] The standard organizes data into a logical block address space, featuring volume descriptors (such as Primary and Supplementary Volume Descriptors), path tables for efficient directory navigation, and directory records that identify files as extents of data sections.[3] It supports three nested levels of interchange: Level 1 imposes strict 8.3 filename formats (up to 8 characters for the name and 3 for the extension, using uppercase A-Z, 0-9, and underscores) for maximum portability; Level 2 relaxes filename length limits while maintaining single-file-section constraints; and Level 3 allows packet writing and fewer restrictions for advanced applications.[3] ISO 9660 serves as the foundational file system for optical media, including CD-ROMs, DVDs, and Blu-ray discs, and forms the basis for ISO image files, which are sector-by-sector copies used to distribute software, databases, and multimedia content.[6] Notable extensions include the Joliet specification, which builds on ISO 9660 to incorporate Unicode (UCS-2) support for international characters, longer identifiers up to 128 bytes, and unlimited directory depths, enhancing usability in modern operating systems.[3]

Introduction and History

Overview

ISO 9660, officially designated as ISO/IEC 9660:1988, is an international standard published by the International Organization for Standardization (ISO) and the International Electrotechnical Commission (IEC) that specifies the volume and file structure for compact read-only optical discs (CD-ROMs) to enable standardized information interchange between diverse information processing systems.[1] The standard defines attributes of volumes, descriptors for metadata, relationships within volume sets, file placement rules, and file attributes, while also specifying structures for input/output data streams organized as record sets.[1] At its core, ISO 9660 organizes data in a sector-based layout using fixed-size logical sectors of 2048 bytes each, which aligns with the physical sectoring of optical media, and implements a hierarchical directory structure that allows files to be arranged in a tree-like fashion for efficient navigation and access.[7][8] This design emphasizes cross-platform compatibility, ensuring that the file system can be read by various operating systems without requiring vendor-specific software or hardware adaptations, thereby supporting reliable data interchange in heterogeneous environments.[9] The fundamental components of ISO 9660 include volumes, which encapsulate the entire content of a disc or a collection of discs; directories and files, which form the basis of the hierarchical organization; and descriptors, such as primary and supplementary volume descriptors, that provide essential metadata to facilitate universal readability and integrity verification across systems.[1] While originally tailored for CD-ROMs, the ISO 9660 format is extensible and commonly applied to other optical media including DVDs and Blu-ray discs, and it can also be utilized on non-optical storage devices such as USB drives and hard disks when compatibility with optical disc readers is desired.[10][11] A key advantage of this vendor-neutral standard is its ability to ensure files remain accessible across different operating systems without proprietary dependencies, promoting broad interoperability for data distribution and archival purposes.[9] To overcome certain constraints in the base specification, such as filename length and character set limitations, extensions like Rock Ridge and Joliet have been developed.[12]

Development History

In the mid-1980s, the rapid adoption of CD-ROM technology for software distribution and data storage highlighted the absence of a standardized file system, leading major technology companies including Apple, Microsoft, and Sony to convene at the High Sierra Hotel in Lake Tahoe, Nevada, in 1985. This meeting formed the High Sierra Group, an ad hoc working group of industry representatives, which proposed the High Sierra Format in May 1986 as a platform-independent structure for organizing files on CD-ROMs.[13][3] The High Sierra proposal was quickly submitted to Ecma International, where it was adopted with modifications as ECMA-119 in December 1986, establishing an international baseline for CD-ROM volume and file structures. This document was then fast-tracked to the International Organization for Standardization (ISO) through a joint ISO/IEC working group, resulting in the publication of ISO 9660 as the first edition in 1988, which refined the format to enhance interoperability while maintaining core principles from High Sierra.[6][3][14] The primary motivation behind ISO 9660 was to create a unified, read-only file system that could support cross-platform access to the vast storage capacity of CD-ROMs—up to 650 megabytes per disc—facilitating widespread use in personal computing and multimedia applications during the 1980s. Key contributors from the ISO working group included representatives from U.S. and Japanese firms, building on the collaborative efforts of the High Sierra Group to address fragmentation in early CD-ROM implementations.[13][3] Early adoption of ISO 9660 faced compatibility challenges due to subtle differences from the High Sierra Format, such as variations in volume descriptors, path tables, and directory record fields, which caused issues in mounting and reading discs on existing software and hardware. These discrepancies, including slower performance in initial Macintosh implementations for large directories, prompted the development of extensions to mitigate limitations without altering the core standard. A minor revision in ISO 9660:1999 provided clarifications on implementation details but introduced no major structural changes.[15][6][12]

Core Specifications

Volume Structure

The volume structure of an ISO 9660 filesystem defines the top-level organization of a CD-ROM, ensuring interoperability for data interchange. It begins with a system area comprising the first 16 logical sectors (sectors 0 through 15), each 2048 bytes in size, reserved for implementation-specific use by the originating system and not interpreted by the interchange system.[16] Following this, the volume descriptor set starts at logical sector 16 and consists of one or more 2048-byte volume descriptors that provide essential metadata about the volume.[16] These descriptors precede the path tables, root directory record, and data area, with the entire volume addressed in 2048-byte logical blocks.[16] The primary volume descriptor (PVD), which is mandatory and typically located at sector 16, has a type value of 1 in byte 1 and follows a fixed 2048-byte format with the standard identifier "CD001" in bytes 2 through 6.[16] Key fields include the volume identifier (bytes 41 through 72, up to 32 bytes of d-characters for the volume name), the volume creation date and time (bytes 814 through 830, in a 17-byte format based on the year 1900 as YYYYMMDDHHMMSScc;1, where cc represents hundredths of a second and ;1 the GMT offset), the abstract file identifier (bytes 740 through 776, up to 8 d-characters plus a 3-character extension pointing to a file containing an abstract), and the publisher identifier (bytes 319 through 446, up to 128 a-characters for the publisher's name).[16] The PVD also specifies the logical block size (bytes 129 through 132, set to 2048), the locations and sizes of the path tables (bytes 133 through 140 for size and 141 through 156 for little- and big-endian table locations), and the root directory record (bytes 157 through 190).[16] Many fields include reserved or unused areas to maintain structural consistency across implementations.[16] An optional enhanced volume descriptor (EVD, type 4) may follow to support directory depths greater than 8 levels and file identifiers up to 207 characters.[16] Additional descriptors may follow the PVD in the set. The volume descriptor set terminator (VDST), with type 255, marks the end of the descriptor sequence and consists of all zero bytes except for the "CD001" identifier and type field.[16] An optional supplementary volume descriptor (SVD), type 2, can extend the PVD with support for alternative character sets or other enhancements, mirroring much of the PVD's structure.[16] For bootable media, an optional boot record volume descriptor (BVD), type 0, provides boot information, linking to boot catalogs as used in extensions like El Torito.[16] The path tables referenced in the PVD enable navigation to directories, including the root directory at the specified sector (often after the descriptors, such as sector 19 in minimal volumes).[16] The data area then holds the actual file contents, path tables, and directory records.[16]

Path Tables and Directories

ISO 9660 employs path tables and directory records to establish a hierarchical navigation system for locating files and subdirectories on the volume. The path tables provide a compact index of all directories, facilitating efficient traversal without scanning the entire directory structure. There are two path tables in the Path Table Group: the Type L path table, which records data in little-endian byte order (least significant byte first), and the Type M path table, which uses big-endian byte order (most significant byte first). These tables list all directories except the root, ordered first by directory level, then by parent directory number, and finally by directory identifier.[16] The location of the path tables is specified in the Primary Volume Descriptor (PVD), with the starting logical block address for the Type L path table at byte positions 141-144 and for the Type M at 149-152; optional secondary locations follow at 145-148 and 153-156, respectively. The total size of each path table is indicated as a 32-bit value at byte positions 133-140 in the PVD. Each entry in a path table is a fixed-size record consisting of the length of the directory identifier (1 byte), the length of the extended attribute record (1 byte), the location of the extent containing the directory (4 bytes), the parent directory number (2 bytes), and the variable-length directory identifier itself, padded to an even byte boundary if necessary. This structure enables quick lookup of a directory's location and its position in the hierarchy relative to its parent.[16] Directories in ISO 9660 are treated as special files containing ordered sequences of directory records, which describe subdirectories and files within them. The root directory record is located at a fixed position in the PVD, spanning byte positions 157-190, and points to the extent holding the root directory's contents. Every directory, including the root, includes a self-referential record for its parent directory (or directory number 0 for the root itself) as the first entry, followed by the "." (self) entry and ".." (parent) entry if applicable, and then records for other contents. Each directory record begins with a 33-byte fixed header that includes the length of the entire record (1 byte), the extended attribute record length (1 byte), the location of the extent for the file or subdirectory data (8 bytes), the data length (8 bytes), and the recording date and time (7 bytes). The header continues with file flags (1 byte), file unit size (1 byte, typically 0), interleave gap size (1 byte, typically 0), volume sequence number (4 bytes, typically 1), and the length of the file identifier (1 byte).[16] Following the fixed header, the variable-length file identifier occupies up to the specified length, restricted in Level 1 interchange to an 8-character d-character name (A-Z, 0-9, underscore) followed by a period and up to a 3-character d-character extension, with no lowercase letters or special characters permitted. The file flags byte uses bit 0 to indicate a hidden file, bit 1 for a directory (set for all directory records), and bit 2 for an associated file, among other attributes. The record ends with padding to a multiple of 2 bytes, ensuring even alignment. For enhanced readability, the following table outlines the structure of a directory record header:
Byte PositionsField NameSize (bytes)Description
1Length of Directory Record1Total length of this record
2Extended Attribute Length1Length of associated extended attributes
3-10Extent Location8Logical block address of the extent (4 little-endian + 4 big-endian)
11-18Data Length8Length of the file or directory data (4 little-endian + 4 big-endian)
19-25Recording Date and Time7Timestamp of creation/modification
26File Flags1Bit flags (e.g., hidden, directory)
27File Unit Size1Typically 0
28Interleave Gap Size1Typically 0
29-32Volume Sequence Number4Typically 1 (2 little-endian + 2 big-endian)
33Length of File Identifier1Bytes in the following identifier
34+File IdentifierVariableName up to 8+3 characters (Level 1)
EndPadding0 or 1To even byte boundary
This format allows directories to reference their contents directly by extent location.[16] The hierarchical structure imposes a maximum depth of 8 directory levels, including the root, to ensure compatibility across implementations. File identifiers must adhere to strict rules: no lowercase letters, no special characters beyond the period separator, and names padded with spaces if shorter than the maximum. In Level 3 interchange, directories may consist of multiple non-contiguous extents, but the records within a single directory must remain sequential and non-interleaved to maintain order. The volume descriptors, such as the PVD, point to the initial path table locations to bootstrap navigation.[16]

File Entries and Data

In ISO 9660, individual files are represented through directory records, which serve as the core entries detailing file attributes and locations within the file system's directory structure. Each directory record has a variable length but begins with a fixed 33-byte header that includes essential metadata: the length of the entire record (1 byte), the length of any optional extended attribute record (1 byte), the logical block address (LBA) of the file's extent (8 bytes), the data length of the file section (8 bytes), the recording date and time (7 bytes in year-month-day-hour-minute-second-GMT offset format), file flags (1 byte indicating attributes such as read-only via the "not read permitted" bit or hidden via the "hidden file" bit), file unit size (1 byte for interleaving), interleave gap size (1 byte), and volume sequence number (4 bytes).[16] Following this header is the file identifier field (variable length, up to 222 bytes in the base format), padded if necessary to an even byte boundary, and optionally followed by system use fields for extensions.[16] File identifiers in directory records adhere to specific naming conventions to ensure interoperability across systems. For Level 1 compliance, the strictest interchange level, identifiers follow an 8.3 DOS-style format: up to 8 uppercase characters for the file name, a period separator, up to 3 uppercase characters for the extension, and a version number (typically 1, ranging from 1 to 32,767), all using d-characters (A-Z, 0-9, and underscore).[16] Level 2 relaxes this to allow longer names up to 30 characters using d1-characters (adding lowercase letters), while Level 3 permits arbitrary lengths up to 204 characters without versions or extensions, supporting more flexible naming agreed upon by implementations.[16] Directory records for the same file across volumes include the version to distinguish entries, but implementations often default to version 1 for simplicity.[16] File data is stored in one or more extents, which are contiguous sequences of logical blocks on the disc. In Levels 1 and 2, files must be recorded as single-section extents without interleaving or gaps, ensuring the data occupies consecutive blocks starting from the specified LBA, with the total size given by the data length field.[16] Level 3 introduces support for multi-extent files, where non-contiguous data is handled by chaining directory records: the first record points to the initial extent, and subsequent records (marked with the multi-extent flag) link to additional extents via identical file identifiers and incremented sequence numbers in the volume sequence field.[16] This allows for larger or fragmented files without violating the base standard's sector-based addressing, though the base ISO 9660 does not support automatic defragmentation.[16] Associated files provide a mechanism for supplementary data linked to a primary file entry. A directory record can designate an associated file using the associated file flag, typically for storing extended attributes such as permissions or ownership, which are recorded in a separate extent referenced by the associated record's LBA.[16] These are optional in the base standard and often utilized by extensions like Rock Ridge for Unix-like attributes, but the core format limits them to basic linkages without predefined semantics.[16] Access to file data occurs through logical block numbers (LBNs) mapped directly to physical sectors on the CD-ROM, with each extent's starting LBN and length enabling sequential reads from the specified positions.[16] Directory records within parent directories provide these navigation pointers, allowing implementations to traverse the hierarchy and retrieve file contents without inherent support for fragmentation resolution in the base specification.[16]
FieldByte PositionSize (bytes)Description
Length of Directory Record11Total length of this record
Extended Attribute Record Length21Size of optional extended attributes
Extent Location3-108LBA of the file's data extent (4 little-endian + 4 big-endian)
Data Length11-188Size of the file section in bytes (4 little-endian + 4 big-endian)
Recording Date and Time19-257Timestamp of file recording
File Flags261Bit flags (e.g., read-only, hidden, multi-extent)
File Unit Size271Size of interleaved units (0 for non-interleaved)
Interleave Gap Size281Gap between interleaved units
Volume Sequence Number29-324Volume number for multi-volume files (2 little-endian + 2 big-endian)
Length of File Identifier331Length of the following file name field
File Identifier34 to 33 + LengthVariableFile name, extension, and version
[16]

Size and Addressing Limits

ISO 9660 imposes specific constraints on volume capacity and addressing to ensure compatibility across diverse systems, primarily tailored for optical media like CD-ROMs. The volume space is addressed using 32-bit unsigned logical block numbers (LBNs), allowing a maximum of 4,294,967,295 logical blocks starting from LBN 0.[16] The logical block size is fixed at a minimum of 2048 bytes, though it can be a larger power of 2 if specified in the volume descriptor; this results in a theoretical maximum volume capacity of approximately 8.8 terabytes when using 2048-byte blocks.[16] However, practical implementations on CD-ROM media limit the usable capacity to around 700 megabytes due to the physical constraints of 80-minute discs in Mode 1 format.[17] File sizes are governed by the extent addressing mechanism, where each extent is a contiguous sequence of logical blocks referenced by a 32-bit LBN and a 32-bit length in bytes. In interchange Levels 1 and 2, files must consist of a single extent, capping the maximum file size at 4,294,967,295 bytes (just under 4 gigabytes).[16] Level 3 relaxes this by permitting multiple extents per file, enabling sizes up to the full volume capacity, though this increases complexity for reading systems.[16] These levels define interoperability: Level 1 enforces strict 8.3 filename formats (8 characters for the name, 3 for the extension, using only uppercase A-Z, 0-9, and underscore), contiguous files, and ensures broad compatibility; Level 2 allows longer filenames up to 30 characters total (name plus extension, excluding the dot and version) while maintaining contiguous files and uppercase d-characters; Level 3 supports non-contiguous files and directories, longer names with lowercase a-characters, and is suited for incremental recording like packet writing.[16] Directory structures face similar bounds to promote reliable interchange. The maximum directory depth is 8 levels from the root for Levels 1 and 2 using primary or supplementary volume descriptors.[16] The total path length—the sum of the lengths of all directory identifiers, the file identifier, and the depth (number of directories)—must not exceed 255 characters in d-characters for primary/supplementary volumes.[16] There is no hard limit on the number of files or subdirectories per directory, as it depends on the directory record packing within 2048-byte sectors, but for Level 1 interchange, a practical limit of around 100 entries is recommended to avoid compatibility issues across implementations.[18] In Level 3, directories can also be non-contiguous, further extending flexibility at the cost of stricter reader requirements.[16]

Extensions and Variants

SUSP and Rock Ridge

The System Use Sharing Protocol (SUSP), defined in IEEE P1281 draft standard version 1.12 adopted in 1994, establishes a general framework for extending ISO 9660 by structuring the optional System Use area within directory entries, which is limited to a maximum of 128 bytes per entry.[19] This protocol enables multiple independent extensions to share the System Use area without conflicts by using a tagged format consisting of two-character identifiers followed by data fields.[19] Key elements include the Continuation Entry (CE) tag for referencing additional data in subsequent directory records when the initial area is insufficient, the Suspension Protocol (SP) tag to temporarily halt processing for other extensions, and the System Use Termination (ST) tag to mark the end of extension data.[19] Building on SUSP, the Rock Ridge Interchange Protocol (RRIP), outlined in IEEE P1282 draft standard version 1.12 from 1994, introduces POSIX-compliant attributes to ISO 9660 volumes for better Unix-like system interoperability.[20] It employs SUSP tags to encode features such as file permissions via the POSIX Attributes (PX) entry, user and group ownership through the POSIX Numbers (PN) entry, symbolic links with the Symbolic Link (SL) entry, and extended filenames up to 255 characters using the Name (NM) entry, which supports arbitrary 8-bit characters excluding null and slash.[20] Additional RRIP-specific fields cover device numbers (TF tag for major and minor identifiers), multiple extended timestamps (TS tag for creation, modification, access, and backup times), and sparse file representation (SF tag to indicate non-contiguous data blocks).[20] In implementation, RRIP is signaled by setting the System Identifier field in the Supplementary Volume Descriptor (SVD) to "RRIP-1991A", corresponding to early versions 1.09 and 1.10 of the protocol, which permits deep directory hierarchies beyond ISO 9660's eight-level limit and preserves case-sensitive naming.[20] These extensions maintain full backward compatibility, as the base ISO 9660 structure remains intact and unaltered, allowing standard readers to ignore the System Use area without errors; however, accessing RRIP features requires software that parses SUSP records.[19]

Joliet and Romeo

Joliet is a Microsoft-developed extension to the ISO 9660 file system, introduced in 1995 to enhance compatibility with Windows operating systems by supporting longer filenames and international characters through Unicode (UCS-2) encoding.[21][22] It achieves this via a Supplementary Volume Descriptor (SVD) that parallels the primary volume descriptor, using the same identifier "CD001" but designated as type 2, allowing optical disc readers to access an alternative file structure while maintaining full backward compatibility with standard ISO 9660 implementations.[23] This dual-descriptor approach ensures that legacy systems, such as those relying on DOS, can still read the base ISO 9660 volume without disruption.[21] The core features of Joliet include filenames of up to 64 Unicode characters, a total path length limited to 255 characters, and deeper directory hierarchies beyond the 8-level depth restriction of base ISO 9660, significantly relaxing the constraints such as its 8.3 filename format.[24][25] Directory entries retain the 2048-byte sector alignment of ISO 9660 but incorporate escape sequences to handle UCS-2 encoding, enabling non-contiguous file placement while preserving sector-based organization.[23] Joliet is compatible with ISO 9660 interchange levels while providing Windows-native long filename recognition and case sensitivity.[21][26] Romeo serves as a supplementary variant to Joliet, allowing filenames up to 128 characters using extended ASCII without Unicode support.[24][25] Unlike Joliet's focus on international character sets, Romeo emphasizes extended ASCII for Windows 95-era long filenames, often appearing alongside Joliet on discs to provide fallback options for systems lacking full Unicode handling.[26] This variant maintains backward compatibility through the same SVD mechanism to support deeper or more complex directory hierarchies, making it useful for software distribution on official Windows installation media.[26] The primary advantages of Joliet and Romeo lie in their ability to bridge the gap between ISO 9660's rigid structure and Windows' demand for user-friendly naming conventions, allowing discs to store files with descriptive, multilingual names up to the specified limits without compromising readability on non-Windows platforms via the base ISO fallback.[21][25]

El Torito

El Torito is a specification developed by Phoenix Technologies in collaboration with IBM for enabling bootable CD-ROMs within the ISO 9660 file system framework.[27] Announced in November 1994 and formally documented in January 1995, it extends ISO 9660 by defining a standardized method for BIOS firmware to recognize and load boot code from optical media without altering the core file system structure. (archived via https://web.archive.org/web/20051104022221/http://www.phoenix.com/NR/rdonlyres/98D3219C-9CC9-4E24-91FF-DFAE4190D1B7/0/ElTorito.pdf) The specification ensures backward compatibility, allowing non-bootable ISO 9660 volumes to remain functional on systems that do not support booting.[27] The integration occurs through a Boot Record Volume Descriptor, positioned at logical sector 17 (immediately following the standard ISO 9660 volume descriptors), which contains a pointer to the Boot Catalog.[27] This descriptor uses a specific identifier ("EL TORITO SPECIFICATION") to signal its presence and includes fields for the catalog's location and length, all formatted in 2048-byte sectors to align with CD-ROM block sizes.[27] The Boot Catalog itself is a contiguous area starting with a Validation Entry that confirms the catalog's integrity via a checksum and identifies the boot media type and manufacturer ID, followed by boot entries organized into sections.[27] Each section begins with a header specifying the platform ID (e.g., 0x00 for x86 BIOS) and an optional ID string, then lists one or more Boot Entries that define selectable boot options.[27] Boot Entries describe how to load and execute boot images, supporting three emulation modes to mimic traditional BIOS boot processes: no-emulation, hard disk emulation, and floppy disk emulation.[27] In no-emulation mode (media type 0), the BIOS loads the boot image directly into memory at a specified load segment (default 07C0h for x86) and transfers control without simulating hardware, allowing raw code execution.[27] Hard disk emulation (media type 4) treats the image as a partitioned hard drive, loading its boot sector via INT 13h extensions, while floppy emulation (media types 1 for 1.2 MB, 2 for 1.44 MB, or 3 for 2.88 MB) maps the image to a virtual floppy disk geometry for sector-by-sector access.[27] Each entry specifies the boot file's location within the ISO 9660 file system, image size in virtual 512-byte sectors (up to 32 MB limit), and optional parameters like sector count and head count for emulated media.[27] Boot images can be either a boot sector (for direct loading) or a full disk image file stored as a regular ISO 9660 file, such as a 1.44 MB floppy image containing an operating system loader.[27] The specification supports multiple entries per catalog for selection criteria, including extensions for additional indicators like bootable flags or user prompts, enabling hybrid setups for different hardware.[27] The entire Boot Catalog is self-contained within ISO 9660, ensuring that the volume remains readable on non-booting systems, with the BIOS INT 13h interface handling the emulation transparently.[27] Originally designed for BIOS-based systems, El Torito has limitations in supporting larger images or modern firmware without extensions.[27] For UEFI/EFI compatibility, the no-emulation mode is repurposed with a platform ID of 0xEF, where the firmware interprets the image not as raw code but as an EFI System Partition on a block device, loading the EFI boot loader (e.g., from \EFI\BOOT\BOOTX64.EFI) directly rather than emulating memory jumps. This adaptation, defined in the UEFI specification, allows El Torito volumes to boot on UEFI systems while preserving BIOS fallback via separate catalog entries.

Apple and Other Extensions

Apple Computer introduced proprietary extensions to ISO 9660 during the late 1980s and early 1990s to facilitate better compatibility with Macintosh systems, allowing CDs to preserve key Hierarchical File System (HFS) attributes without violating the core ISO 9660 standard. These extensions primarily leverage the optional System Use field within directory records to encode Macintosh-specific metadata, such as 4-character file type and creator codes (e.g., "TEXT" for plain text files and "hscd" for High Sierra tools), which enable the Mac OS Finder to correctly identify and handle files.[15] To support resource forks—a fundamental Macintosh feature for storing application resources separate from data—the extensions designate resource fork content as an associated file linked to the primary data fork file via the directory entry, ensuring both components are accessible during mounting. Limited HFS Finder information is also incorporated into the System Use field, including specific bit flags (e.g., bits 5, 12, 13, and 15) for attributes like file visibility, locked status, or bundle identification. For enhanced internationalization, Supplementary Volume Descriptors (SVDs) are utilized, often with custom escape sequences to accommodate non-ASCII character sets beyond the base ISO 9660's ASCII limitations. Apple-specific date formats are embedded in volume descriptors to align with Macintosh timestamp precision, incorporating a GMT offset byte absent in earlier High Sierra proposals for more accurate cross-platform time representation.[15] These extensions typically employ SVDs identified by "CDROM" (echoing High Sierra roots) or custom identifiers to signal Macintosh compatibility, while maintaining full adherence to ISO 9660's primary volume descriptor for broad interoperability. Implementation involves combining them with the base ISO 9660 structure during disc authoring, but reading requires platform-specific drivers, such as Apple's Foreign File Access and ISO 9660 File Access extensions in classic Mac OS System Folders.[15] Beyond Apple's contributions, several niche extensions address specialized use cases. The CD-RTOS (Compact Disc Real-Time Operating System) extension, defined for Philips' CD-Interactive (CD-I) format in the Green Book standard, augments ISO 9660 with real-time scheduling and interleaving capabilities to support interactive multimedia applications, enabling synchronized audio, video, and data playback under a dedicated OS kernel. Similarly, CD-WO (Compact Disc Write-Once) provisions, outlined in the Orange Book Part II, extend ISO 9660 for incremental recording on write-once media like CD-R, permitting multi-session updates while preserving read-only file structure integrity for subsequent mounts. ECMA-167 (equivalent to ISO/IEC 13346), the foundational specification for Universal Disk Format (UDF), includes bridging mechanisms to integrate with ISO 9660 on hybrid volumes, allowing seamless coexistence of both file systems on the same disc for backward compatibility in rewritable and DVD media. These extensions are generally layered atop the base ISO 9660 framework and necessitate specialized readers or hybrid-aware software for full functionality. Though largely superseded by Joliet, UDF, and native HFS+ in modern contexts, Apple and other extensions persist in archival scenarios, with contemporary tools like macOS's Disk Utility or Linux's isofs module capable of parsing them to extract legacy Macintosh metadata from vintage CDs. These extensions, including Apple-specific ones, continue to be parsed by modern tools in disc images for archival and compatibility purposes as of 2025.[6]

Implementation and Usage

Disc Images

An ISO 9660 disc image, commonly known as an .iso file, is a digital file that serves as a sector-by-sector copy of an optical disc formatted according to the ISO 9660 standard, capturing the complete structure from the system area through the data area to the lead-out.[6] This exact replication preserves the disc's logical layout, including boot sectors, volume descriptors, path tables, directories, and file data, allowing the image to function identically to the physical medium when mounted or burned.[13] The format ensures architecture-independent readability across systems, making it ideal for archiving and distribution of data such as software or multimedia.[28] Disc images are typically created using specialized software that builds the ISO 9660 filesystem from a directory tree on a host system. Tools like mkisofs from the cdrtools suite take a snapshot of files and directories, generating a binary image compliant with ISO 9660, including options for extensions like Joliet or Rock Ridge.[29] Genisoimage, a fork of mkisofs developed under the cdrkit project, offers similar functionality for producing ISO 9660 images, with added support for hybrid formats and UDF integration.[30] More advanced tools such as xorriso, part of the GNU project, enable creation, manipulation, and writing of ISO 9660 images, supporting multi-session updates and grafting of filesystems.[31] The internal structure of an ISO 9660 disc image mirrors that of a physical disc, consisting of 2048-byte sectors with padding to align data boundaries and ensure compatibility during burning.[6] Images support multi-track configurations for multi-session discs, where additional sessions append data without altering prior content, and hybrid formats combine ISO 9660 with other filesystems like HFS for cross-platform compatibility.[32] This layout includes reserved areas for system use and extends to the lead-out, often filled with zeros to match the disc's full sector count. In practice, ISO 9660 disc images are mounted as virtual drives to access contents without physical media, such as using loopback devices in Linux to treat the file as a block device.[33] They are also burned to blank optical discs for replication or distributed digitally, commonly for software installers and operating system distributions that require a standardized, portable format.[34] Pure ISO 9660 images adhere strictly to the base standard without additional filesystems, while hybrids incorporate UDF for larger capacities or FAT for broader compatibility, often in bridge formats that maintain ISO 9660 as the primary structure.[21] The file size of these images generally corresponds to the target disc's capacity, such as approximately 650 MiB for a standard CD-ROM, encompassing all sectors including unused space.[6]

Platform Support and Compatibility

Microsoft Windows provides native support for reading ISO 9660-formatted discs through the Compact Disc File System (CDFS) driver, which has been included since Windows 95.[35] This driver enables access to base ISO 9660 structures, with Joliet extensions preferred for improved long filename support on modern versions.[26] Writing capabilities are available via the Image Mastering API (IMAPI), which supports ISO 9660 alongside Joliet and UDF formats for creating data discs.[21] Third-party tools like ImgBurn offer additional options for authoring and burning ISO 9660 images, often with enhanced control over levels and extensions.[36] In Linux and Unix-like systems, ISO 9660 is handled by the kernel's cdrom module and the isofs filesystem driver, which mounts discs as read-only filesystems.[37] The isofs driver provides full support for Rock Ridge and System Use Sharing Protocol (SUSP) extensions, allowing preservation of Unix permissions, symbolic links, and longer filenames.[37] For creation and burning, tools such as mount handle reading, while growisofs serves as a frontend to mkisofs for generating and writing ISO 9660 volumes, including multisession support on DVD media.[38] macOS natively supports reading ISO 9660 discs, particularly in hybrid formats combining ISO 9660 with HFS or HFS+ for cross-platform compatibility.[39] It accesses base ISO 9660 structures and Apple-specific extensions seamlessly, enabling Macintosh users to view files intended for other platforms.[15] Disk Utility facilitates the creation of ISO 9660 disc images, though advanced hybrid authoring may require additional software like Toast for full HFS/ISO integration.[40] On older platforms like MS-DOS, ISO 9660 access is provided through extensions such as MSCDEX, which enables CD-ROM drives to present the filesystem as a drive letter.[41] Embedded systems and game consoles often feature partial ISO 9660 support; for instance, the Sony PlayStation uses ISO 9660 for game discs, while the original Xbox handles it via UDF/ISO hybrids for compatibility.[42] Cross-platform libraries like libcdio offer programmatic access to ISO 9660 on various systems, supporting reading and extraction without OS-specific dependencies.[43] Key compatibility challenges include handling endianness in path tables, where ISO 9660 allows both little-endian and big-endian encodings for 16- and 32-bit integers, potentially requiring drivers to support multiple formats for robust interoperability.[11] Incomplete support for extensions like Rock Ridge or Joliet can force systems to fall back to base ISO 9660's restrictive 8.3 filename format (eight characters for the name, three for the extension, uppercase only), limiting usability on platforms expecting longer or case-sensitive names.[8]

Limitations and Modern Context

Inherent Constraints

ISO 9660 imposes stringent naming restrictions to facilitate interchange across diverse systems, particularly in its Level 1 configuration, which mandates file identifiers consisting of a maximum of eight characters for the base name and three for the extension, separated by a period.[3] Only uppercase letters (A-Z), digits (0-9), and underscores (_) are permitted, forming the set of 37 "d-characters" defined in the standard, with no allowance for spaces, lowercase letters, or special symbols.[3] This 8.3 format, reminiscent of early DOS conventions, severely hampers the use of descriptive or user-friendly filenames common in contemporary computing, often requiring truncation or renaming that can lead to conflicts or loss of meaning.[3] The directory hierarchy is capped at eight nested levels for interchange Levels 1 and 2, restricting the organization of complex folder structures.[3] Each directory entry consumes a fixed minimum of 34 bytes (plus the length of the identifier), and given the 2048-byte logical sector size, practical limits constrain directories to approximately 100 files or subdirectories to avoid spanning multiple sectors inefficiently.[18][3] These bounds make ISO 9660 unsuitable for deeply nested or populous file trees, such as those in software distributions or multimedia archives. As a file system tailored for read-only media like CD-ROM, ISO 9660 lacks any provisions for writing, in-place modifications, or deletions after volume creation.[3] File attributes are confined to basic flags for existence, directory status, and hidden or system designations, without support for granular permissions, timestamps beyond creation, or access controls.[3] This immutable design ensures data integrity on optical media but precludes dynamic updates, rendering it incompatible with writable or editable storage needs. Character encoding in ISO 9660 adheres strictly to the 7-bit ECMA-6 coded character set for information interchange, limiting identifiers to the aforementioned d-characters and excluding lowercase, accented, or non-ASCII symbols.[3] This ASCII subset supports only English-language naming, posing significant barriers for international or multilingual content where characters from extended sets (e.g., ISO 8859) are required.[3] Additional drawbacks stem from the fixed 2048-byte logical sector size, which mandates padding for files smaller than this threshold, resulting in substantial wasted space on volumes with many tiny files.[3] The standard includes no native support for data compression to mitigate storage inefficiencies or encryption to protect contents, further limiting its applicability in bandwidth-constrained or security-sensitive scenarios.[3] These constraints prompted the creation of extensions to enhance functionality while preserving backward compatibility.[3]

Current Applications and Alternatives

In 2025, ISO 9660 remains a foundational format for bootable installers, particularly in Linux distributions, where .iso image files are downloaded and used to create installation media on optical discs or USB drives. For instance, major distributions like Ubuntu, Fedora, and Debian continue to provide official ISO 9660-based images for live booting and installation, ensuring compatibility with a wide range of hardware and virtualization environments. Beyond operating system deployment, ISO 9660 persists in software distribution archives and virtual machine images, where it serves as a reliable container for bundled executables, documentation, and bootable environments. Tools such as VirtualBox and VMware routinely mount ISO 9660 files to simulate optical media for testing and deployment. In forensic preservation, the format is employed to create verifiable disk images of legacy optical media, allowing investigators to capture and analyze data without altering originals, as supported by open-source tools like those in the Digital Forensics Framework.[44] The format's longevity is evident in ongoing software support, including IsoBuster's version 5.6 release in May 2025, underscoring its role in data extraction from aging media. .iso files remain ubiquitous for cross-platform compatibility in archival and emulation contexts.[45] As an alternative to ISO 9660, the Universal Disk Format (UDF, standardized as ISO/IEC 13346) has largely supplanted it for DVDs and Blu-ray discs, offering write-once and rewritable support, longer filenames (up to 255 characters), and better handling of large files exceeding 4 GB—features absent in ISO 9660's read-only design. UDF's adoption stems from its flexibility for modern optical media, though it requires specific drivers for full compatibility. For USB drives and non-optical storage, exFAT and FAT32 are preferred alternatives due to their broad cross-device readability, lack of optical-specific constraints, and support for partitions up to 128 PB in exFAT, making ISO 9660's use on USBs increasingly niche. Overall, ISO 9660's application on new optical media is declining in favor of UDF.[46][47] Hybrid formats combining ISO 9660 with UDF, often called UDF Bridge, are still common for video DVDs to ensure playback on legacy devices that recognize only ISO 9660 while leveraging UDF for enhanced features on newer players. This approach maintains broad compatibility in consumer media.[21] Looking ahead, ISO 9660 is maintained primarily for backward compatibility in legacy systems and archival tools, but it is overshadowed by cloud-based file systems and direct digital distribution, reducing the need for physical optical media in contemporary workflows.[48]

References

  1. ISO 9660:1988 - Information processing — Volume and file structure ...
  2. https://www.ecma-international.org/publications-and-standards/standards/ecma-119/
  3. [PDF] ECMA-119, 4th edition, June 2019
  4. ISO 9660:1988/Amd 1:2013 - Information processing
  5. ISO/IEC 9660:2023 - Information processing — Volume and file ...
  6. ISO Disk Image File Format - Library of Congress
  7. ISO9660 Filesystem - The Linux Kernel documentation
  8. ISO 9660 - Just Solve the File Format Problem
  9. ISO9660: Understanding the ISO 9660 File System Standard
  10. What is ISO 9660 and how is it used? - Android Police
  11. ISO 9660 - OSDev Wiki
  12. Standards | pycdlib - GitHub Pages
  13. ISO 9660 — ISO images for computer files - ISO
  14. https://www.iso.org/standard/51280.html
  15. The Ins And Outs Of ISO 9660 And High Sierra - MacTech
  16. F.2 Media Formats - DICOM
  17. [PDF] Chapter 19. Volume Organization and Naming
  18. Disc Formats - Win32 apps - Microsoft Learn
  19. Joliet - OSDev Wiki
  20. Joliet Specification - Pismo Technic
  21. 11.2.2.2. ISO-9660 Variants - PC Hardware in a Nutshell, 3rd Edition ...
  22. What are the "Romeo" and "Joliet" formats when creating a disc with ...
  23. File Systems - IsoBuster
  24. [PDF] “El Torito” Bootable CD-ROM Format Specification - PDOS-MIT
  25. IsoImage - Community Help Wiki - Ubuntu Documentation
  26. Manpage for mkisofs.8 - Cdrtools - SourceForge
  27. genisoimage - create ISO9660/Joliet/HFS filesystem with optional ...
  28. man 1 xorriso - GNU.org
  29. A Time to Listen, a Time to Read Multi-session CDs
  30. How to mount an ISO image/file under Linux - nixCraft
  31. What are ISO image files and how do I use them? - Active@ Boot Disk
  32. Compact Disc File System | Software Wiki - Fandom
  33. ISO 9660 or Joliet or UDF? - ImgBurn Forum
  34. None
  35. growisofs(1) - Linux man page - Die.net
  36. Bootable hybrid (ISO/HFS) CD-ROMs - MacDisk
  37. Burning a hybrid disc? - Apple Support Communities
  38. Optical Drive Downloads - DOS Days
  39. Sony PlayStation - Data Crystal
  40. libcdio/libcdio: Compact Disc (CD) Input and Control Core Library ...
  41. Digital Forensics: Get Started with These 9 Open Source Tools
  42. IsoBuster 5.6 released
  43. What Is UDF File System & Universal Disk Format? - DiskInternals
  44. FAT32 vs. ExFAT vs. NTFS: Which Format Is Best for Your Storage ...
  45. The Definition of ISO 9660 and Its Basics & Features - MiniTool
User Avatar
No comments yet.