View source for ISO 9660

{{short description|File system for CD-R and CD-ROM optical discs}}
{{Use dmy dates|date=July 2021}}
{{Infobox file system
| full_name               =
| developer               = [[International Organization for Standardization|ISO]]/[[International Electrotechnical Commission|IEC]], [[Ecma International]]
| variants                = [[ISO 13490]]
| introduction_date       = {{Start date and age|1988}}
| partition_id            =
| directory_struct        =
| file_struct             =
| bad_blocks_struct       =
| min_volume_size         =
| max_volume_size         = 8&nbsp;[[Tebibyte|TiB]] (nearly 8.8 TB)
| max_file_size           =
| max_files_no            =
| max_filename_size       =
| max_dirname_size        =
| max_directory_depth     =
| dates_recorded          =
| date_range              =
| date_resolution         =
| forks_streams           =
| attributes              =
| file_system_permissions =
| compression             =
| encryption              =
| data_deduplication      =
| OS                      = Cross platform
| bootable                =
| filename_character_set  =
| file_types              =
| file_size_granularity   =
| copy_on_write           =
| website                 =
}}
{{Optical disc authoring}}

'''ISO 9660''' (also known as '''[[Ecma International|ECMA]]-119''') is a [[file system]] for [[CD-ROM|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 system]]s.<ref name=ECMA-119-2019-06 />

ISO 9660 traces its roots to the '''High Sierra Format''',<ref>{{cite journal|title=Working Paper for Information Processing: Volume and File Structure of CD-ROM for Information Interchange|journal=Optical Information Systems|date=January 1987|volume=7|issue=1|pages=29–49}}</ref> 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 [[File Allocation Table|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<ref>{{cite web| url = http://www.ecma-international.org/publications/standards/Ecma-119.htm| title = Volume and File Structure of CDROM for Information Interchange| publisher = Ecma International| date = December 1987| access-date = 5 November 2003| archive-date = 18 November 2016| archive-url = https://web.archive.org/web/20161118181230/http://www.ecma-international.org/publications/standards/Ecma-119.htm| url-status = live}}</ref> and submitted for fast tracking to the [[International Organization for Standardization|ISO]], where it was eventually accepted as ISO 9660:1988.<ref name="ISO9660">{{ cite book | title = Volume and File Structure of CD-ROM for Information Interchange | date = 1988-09-01 | publisher = International Organization for Standardization (ISO) | location = Geneva | edition = corrected }}</ref> Subsequent amendments to the standard were published [[#History|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 script]]s to be used), ''El Torito'' (enables CDs to be [[booting|bootable]]) and the ''Apple ISO 9660 Extensions'' (file characteristics specific to the [[classic Mac OS]] and [[macOS]], such as [[resource fork]]s, file backup date and more).

== History ==
[[Compact disc]]s 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 storage|mass data storage]]. Called [[CD-ROM]]s, the lowest level format for these types of compact discs was defined in the ''[[Rainbow Books|Yellow Book]]'' specification in 1983. However, this book did not define any format for organizing data on CD-ROMs into logical units such as [[computer file|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.<ref name="Peters_1989" /> In September/<ref>{{cite journal |title=Premium Reference Tool of the '90s |journal=[[PC Magazine]] |date=1986-10-14 |pages=150–164 |author-first1=John |author-last1=Helliwell |url=https://books.google.com/books?id=nuXmVNll5JEC&pg=PA154 |access-date=2016-11-18}}</ref> October 1985 several companies invited experts to participate in the development of a working paper for such a standard.

In November 1985, representatives of <!-- sources vary: 12-16 --> computer hardware manufacturers gathered at the High Sierra Hotel and Casino (currently called the [[Golden Nugget Lake Tahoe]]) in [[Stateline, Nevada]].<ref>{{cite book |author-last1=Manes |author-first1=Stephen |author1-link=Stephen Manes |author-last2=Andrews |author-first2=Paul |year=1993 |title=Gates: How Microsoft's Mogul Reinvented an Industry—and Made Himself the Richest Man in America |publisher=[[Doubleday (publisher)|Doubleday]] |page=336 |isbn=0-385-42075-7}}</ref> This group became known as the ''High Sierra Group'' (''HSG''). Present at the meeting were representatives from [[Apple Computer]], [[AT&T]],{{citation needed | date=August 2017}} [[Digital Equipment Corporation]] (DEC), [[Hitachi]], [[LaserData]], [[Microware]],{{citation needed | date=August 2017}} [[Microsoft]], [[3M]], [[Philips]], [[Reference Technology Inc.]], [[Sony Corporation]], [[TMS Inc.]]<!-- Stillwater, Oklahoma, TMSSequoia, 1981+ -->, [[VideoTools]] (later Meridian<ref>{{cite journal|date=June 1987|title=The Future of CD-ROM|url=https://archive.org/details/Atari_Explorer_Volume_7_Number_3_1987-06_Atari_Explorer_Publications_US|journal=Explorer|publisher=Atari Explorer Publications|volume=7|page=[https://archive.org/details/Atari_Explorer_Volume_7_Number_3_1987-06_Atari_Explorer_Publications_US/page/n20 19]|access-date=2016-11-18|author-last=Anderson|author-first=Gregg|number=3}}<!-- https://archive.org/stream/Atari_Explorer_Volume_7_Number_3_1987-06_Atari_Explorer_Publications_US/Atari_Explorer_Volume_7_Number_3_1987-06_Atari_Explorer_Publications_US_djvu.txt --></ref>), [[Xebec Corporation|Xebec]], and [[Yelick]].{{citation needed | date=August 2017}} 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.<ref name="ECMA-119-1">{{cite web |title=Standard ECMA-119: Volume and File Structure of CDROM for Information Interchange |edition=1st |date=December 1986 |url=https://www.ecma-international.org/wp-content/uploads/ECMA-119_1st_edition_december_1986.pdf}}</ref> 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.<ref name="ECMA-119-2">{{cite web |title=Standard ECMA-119: Volume and File Structure of CDROM for Information Interchange |url=https://www.ecma-international.org/wp-content/uploads/ECMA-119_2nd_edition_december_1987.pdf |access-date=2022-12-30 |edition=reprinted 2nd |date=September 1998<!-- reprinted --> |orig-date=December 1987 |archive-date=15 March 2023 |archive-url=https://web.archive.org/web/20230315015022/https://www.ecma-international.org/wp-content/uploads/ECMA-119_2nd_edition_december_1987.pdf |url-status=live }}</ref><ref>{{cite book |title=The Invention of Compact Discs |url=http://www.bookrags.com/research/the-invention-of-compact-discs-scit-07123456/ |archive-date=5 March 2021 |access-date=24 November 2020 |archive-url=https://web.archive.org/web/20210305165154/http://www.bookrags.com/research/the-invention-of-compact-discs-scit-07123456/ |url-status=live }}</ref><ref>{{cite web |title=Chip's CD Media Resource Center: CD-ROM page 6 |url=http://www.chipchapin.com/CDMedia/cdrom6.php3 |access-date=24 November 2020 |archive-date=26 July 2019 |archive-url=https://web.archive.org/web/20190726064954/http://www.chipchapin.com/CDMedia/cdrom6.php3 |url-status=dead }}</ref> ''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.<ref name="Peters_1989">{{cite journal |author-last=Peters |author-first=Paul Evan |author-link=Paul Evan Peters |title=CD-ROM Standards: The Fate of Z39.60 |journal=Information Standards Quarterly |publisher=[[National Information Standards Organization]] (NISO) |date=July 1989 |volume=1 |issue=3 |pages=1–3 |issn=1041-0031 |url=http://www.niso.org/apps/group_public/download.php/6767/ISQ_vol1_no3_Jul89.pdf |access-date=2016-11-18 |url-status=live |archive-url=https://web.archive.org/web/20161118095423/http://www.niso.org/apps/group_public/download.php/6767/ISQ_vol1_no3_Jul89.pdf |archive-date=2016-11-18}}</ref>

[[Japanese Industrial Standard|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.<ref>{{cite web| url = https://pismotec.com/cfs/iso9660-1999.html| title = JIS X 0606:1998 / ISO 9660:1999 Draft Specification| access-date = 2 January 2019| archive-date = 28 December 2018| archive-url = https://web.archive.org/web/20181228021512/http://pismotec.com/cfs/iso9660-1999.html| url-status = live}}</ref>  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 (file system)|Joliet]] Specification'."<ref>ISO 9660, Amendment 1 (ISO 9660:1988/Amd.1:2013(E))</ref> In December 2017, a 3rd Edition of ECMA-119 was published that is technically identical with ISO 9660, Amendment 1.<ref name=ecma119.3>{{cite web |title=Standard ECMA-119 |url=http://www.ecma-international.org/publications/files/ECMA-ST/Ecma-119.pdf |website=Ecma International |publisher=Ecma |access-date=16 August 2018 |page=vii |archive-date=6 May 2018 |archive-url=https://web.archive.org/web/20180506022153/http://www.ecma-international.org/publications/files/ECMA-ST/Ecma-119.pdf |url-status=live }}</ref>

In 2019, ECMA published a 4th version of ECMA-119, integrating the Joliet text as "Annex C".<ref name=ECMA-119-2019-06>{{web archive |url=http://web.archive.org/web/20230820104314if_/https://www.ecma-international.org/wp-content/uploads/ECMA-119_4th_edition_june_2019.pdf |title=ECMA-119 - Volume and file structure of CDROM for information interchange - 4th edition, June 2019 |access-date=2025-03-10 }} (linked from [https://web.archive.org/web/20240725023816/https://ecma-international.org/publications-and-standards/standards/ecma-119/ ECMA-119 - Ecma International])</ref>

In 2020, ISO published Amendment 2, which adds some minor clarifying matter, but does not add or correct any technical information of the standard.<ref>ISO 9660, Amendment 2 (ISO 9660:1988/Amd.2:2020(E))</ref>

== Specifications ==

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.<ref name="iso9660-simplified" />

=== Top level ===

{| class="wikitable"
|+ ISO 9660 file system
|-
| System area (32,768 B)
| ''Unused by ISO 9660''
|-
| rowspan=3 | 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.<ref name="iso9660-simplified">{{cite web| url = https://pierrelib.pagesperso-orange.fr/filesystems/iso9660_simplified.html| title = ISO9660 Simplified for DOS/Windows| access-date = 26 November 2020| archive-date = 6 March 2021| archive-url = https://web.archive.org/web/20210306020858/https://pierrelib.pagesperso-orange.fr/filesystems/iso9660_simplified.html| url-status = dead}}</ref> While it is suggested that they are reserved for use by [[booting|bootable media]],<ref>{{cite web| url = http://www.brankin.com/main/technotes/Notes_ISO9660.htm| title = ISO9660| access-date = 26 November 2020| archive-date = 7 March 2021| archive-url = https://web.archive.org/web/20210307031047/http://brankin.com/main/technotes/Notes_ISO9660.htm| url-status = live}}</ref> a CD-ROM may contain an alternative file system descriptor in this area, and it is often used by [[hybrid CD]]s to offer [[classic Mac OS]]-specific and [[macOS]]-specific content.{{citation needed|date=November 2020}}

=== Volume descriptor set ===

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 (computing)|header]] for the data area, describing its content (similar to the [[BIOS parameter block]] used by [[File Allocation Table|FAT]], [[High Performance File System|HPFS]] and [[NTFS]] formatted disks).

{| class="wikitable"
|+ 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:

{| class="wikitable"
|+ 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:

{| class="wikitable"
|+ 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 ===

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.<ref>ISO9660 sections 6.9 and 9.4.4</ref>

=== Directories and files ===
[[File:Iso9660directoryTree.png|thumb|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 [[Extent (file systems)|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):<ref name="ISO9660" />

* 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|date=November 2020}}

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 (file systems)|extent]] on disc is stored in a 32 bit value,<ref>ISO 9660 section 9.1.4</ref> it allows for a maximum length of just over 4.2&nbsp;[[gigabyte|GB]] (more precisely, one byte less than 4&nbsp;[[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&nbsp;TB. With this, files larger than 4&nbsp;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|date=August 2020}} [[Linux]] supports multiple extents.<ref>{{cite mailing list | url = http://lists.freebsd.org/pipermail/freebsd-bugs/2006-April/017786.html | title = kern/95222: File sections on ISO9660 level 3 CDs ignored | author = Pete | mailing-list = freebsd-bugs | date = 2 April 2006 | access-date = 19 September 2007 | archive-date = 16 April 2016 | archive-url = https://web.archive.org/web/20160416233130/http://lists.freebsd.org/pipermail/freebsd-bugs/2006-April/017786.html | url-status = live }}</ref>

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.<ref name=ecma119.3/>

=== Volume size ===
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 2<sup>32</sup>-1, limiting the volume size to (2<sup>32</sup>-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 ==
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 script]]s to be used), ''El Torito'' (enables CDs to be [[booting|bootable]]) and the ''Apple ISO 9660 Extensions'' (file characteristics specific to the [[classic Mac OS]] and [[macOS]], such as [[resource fork]]s, file backup date and more).

=== SUSP ===

''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:

* <code>CE</code>: Continuation area
* <code>PD</code>: Padding field
* <code>SP</code>: System use sharing protocol indicator
* <code>ST</code>: System use sharing protocol terminator
* <code>ER</code>: Extensions reference
* <code>ES</code>: Extension selector

Other known SUSP fields include:

* <code>AA</code>: Apple extension, preferred
* <code>BA</code>: Apple extension, old (length attribute is missing)
* <code>AS</code>: Amiga file properties
* <code>ZF</code>: zisofs compressed file, usually produced by program mkzftree or by libisofs. Transparently decompressed by Linux kernel if built with CONFIG_ZISOFS.<ref>{{cite web|title=linux/fs/isofs/Kconfig|website= [[GitHub]]|date= 23 January 2022|url= https://github.com/torvalds/linux/blob/master/fs/isofs/Kconfig}}</ref>
* <code>AL</code>: records [[Extended file attributes|Extended File Attributes]], including [[Access control list|ACLs]]. Proposed by [[libburnia]], supported by libisofs.<ref>{{cite web|title=Arbitrary Attribute Interchange Protocol|url=https://dev.lovelyhq.com/libburnia/web/wiki/AAIP}}</ref>

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 compatibility|forward compatible]] with SUSP; so that, with care, a volume can use both Apple extensions as well as RRIP extensions.

=== Rock Ridge ===
{{redirect|Rock Ridge|the fictional Western town|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.<ref>{{cite web|url=http://www.ymi.com/ymi/sites/default/files/pdf/Rockridge.pdf|title=RRIP (IEEE P1282) Draft Standard 1.12|date=8 July 1994|archive-url=https://web.archive.org/web/20170404043745/http://www.ymi.com/ymi/sites/default/files/pdf/Rockridge.pdf|archive-date=2017-04-04|url-status=dead}}</ref> The standard takes its name from the fictional town ''Rock Ridge'' in [[Mel Brooks]]' film ''[[Blazing Saddles]]''.<ref>{{cite web|title=CDFS The Rock Ridge Interchange Protocol (RRIP, IEEE P1282)|url=http://www.cdfs.com/cdfs-glos-rrip.html|access-date=24 November 2020|archive-date=4 March 2016|archive-url=https://web.archive.org/web/20160304120707/http://www.cdfs.com/cdfs-glos-rrip.html|url-status=live}}</ref> The RRIP extensions are, briefly:

* Longer file names (up to 255 bytes) and fewer restrictions on allowed characters (support for lowercase, etc.)
* UNIX-style [[Unix permissions#Traditional Unix permissions|file modes]], [[user id]]s and group ids, and file [[timestamp]]s
* Support for [[Symbolic link]]s and [[Device file system|device files]]
* Deeper directory hierarchy (more than 8 levels)
* Efficient storage of [[sparse file]]s

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:

* <code>RR</code>: Rock Ridge extensions in-use indicator (note: dropped from standard after version 1.09)
* <code>PX</code>: POSIX file attributes
* <code>PN</code>: POSIX device numbers
* <code>SL</code>: symbolic link
* <code>NM</code>: alternate name
* <code>CL</code>: child link
* <code>PL</code>: parent link
* <code>RE</code>: relocated directory
* <code>TF</code>: time stamp
* <code>SF</code>: 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.<ref>{{cite web|title=Amiga MakeCD Support Page|url=http://www.estamos.de/makecd/|access-date=2017-04-04|language=de|author=Angela Schmidt, Patrick Ohly|archive-date=28 October 2020|archive-url=https://web.archive.org/web/20201028201325/http://www.estamos.de/makecd/|url-status=live}}</ref>

=== El Torito ===
''El Torito'' is an extension designed to allow [[booting]] a computer from a CD-ROM. It was announced in November 1994<ref>{{cite press release | title = Phoenix announces bootable CD-ROM specification; Specification developed jointly by Phoenix and IBM | publisher = Phoenix Technologies Ltd. | date = 1994-11-11 | url = http://www.thefreelibrary.com/Phoenix+announces+bootable+CD-ROM+specification%3b+Specification...-a015922225 | access-date = 2008-01-31 | archive-date = 10 August 2017 | archive-url = https://web.archive.org/web/20170810051304/https://www.thefreelibrary.com/Phoenix+announces+bootable+CD-ROM+specification%3b+Specification...-a015922225 | url-status = dead }}</ref> 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]] ({{coord|33.684722|-117.852547}}).<ref name="Parker">{{ cite news | last = Parker | first = Dana J. | title = Fresh Tortillas and CD-ROM Standards: The El Torito Bootable CD-ROM Specification | periodical = CD-ROM Professional | volume = 8 | issue = 7 | url = http://www.cdpage.com/Compact_Disc_Variations/danaboot.html | archive-url = https://web.archive.org/web/19991008045553/http://www.cdpage.com/Compact_Disc_Variations/danaboot.html | access-date = 2008-01-31 | url-status = usurped | archive-date = 1999-10-08 }}</ref> The initial two authors were Curtis Stevens, of Phoenix Technologies, and Stan Merkin, of IBM.<ref name="Parker" />

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 [[disk image|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 80<sub>hex</sub> ([[hard disk]] emulation), 00<sub>hex</sub> ([[floppy disk]] emulation) or an arbitrary number if the BIOS should not provide emulation. Emulation is useful for booting older [[operating system]]s from a CD, by making it appear to them as if they were booted from a hard or floppy disk.<ref name=osdev/>

[[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 {{code|\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.<ref>{{cite web |title=13. Protocols – Media Access — UEFI Specification 2.10 documentation |url=https://uefi.org/specs/UEFI/2.10/13_Protocols_Media_Access.html#partition-discovery |website=uefi.org |access-date=5 October 2024 |archive-date=7 October 2024 |archive-url=https://web.archive.org/web/20241007101042/https://uefi.org/specs/UEFI/2.10/13_Protocols_Media_Access.html#partition-discovery |url-status=live }}</ref>

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]].<ref name=osdev>{{cite web | url = http://wiki.osdev.org/El-Torito | title = El-Torito | work = OSDev | access-date = 2015-01-03 | archive-date = 27 November 2020 | archive-url = https://web.archive.org/web/20201127061406/https://wiki.osdev.org/El-Torito | url-status = live }}</ref> While the El Torito spec alludes to a "Mac" platform ID, PowerPC-based Apple Macintosh computers don't use it.<ref>{{cite web | url = http://www.macdisk.com/hybbooten.php | title = Bootable hybrid (ISO/HFS) CD-ROMs | access-date = 2014-01-03 | archive-date = 28 February 2021 | archive-url = https://web.archive.org/web/20210228072738/https://www.macdisk.com/hybbooten.php | url-status = live }}</ref>

=== Joliet ===

''Joliet'' is an extension specified and endorsed by [[Microsoft]] and has been supported by all versions of its [[Microsoft Windows|Windows]] [[operating system]] since [[Windows 95]]<ref name="mskb125630">{{cite web | title = Joliet Specification for CD-ROM | id = MSKB 125630 | work = Microsoft Knowledge Base | publisher = Microsoft | date = 2005-07-11 | url = http://support.microsoft.com/kb/125630 | access-date = 2012-05-29 | archive-date = 25 May 2013 | archive-url = https://web.archive.org/web/20130525020325/http://support.microsoft.com/kb/125630 | url-status = live }}</ref> and [[Windows NT 4.0]].<ref>{{cite web | title = Windows NT Support For Long File Names Under CDFS File System | id = MSKB 142372 | work = Microsoft Knowledge Base | publisher = Microsoft | date = 1 November 2006 | url = http://support.microsoft.com/kb/142372 | access-date = 2012-05-29 | archive-date = 17 October 2009 | archive-url = https://web.archive.org/web/20091017140929/http://support.microsoft.com/kb/142372 | url-status = live }}</ref> 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-2]]BE ([[UTF-16]]BE 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.<ref name="mskb125630"/> 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.<ref name=mkisofs>{{man|8|mkisofs|FreeBSD}}</ref> Microsoft has documented it "can use up to 110 characters."<ref>{{cite web | title = 5 Appendix A: Product Behavior | url = http://msdn.microsoft.com/en-us/library/ff469400.aspx | access-date = 13 April 2014 | archive-date = 20 April 2014 | archive-url = https://web.archive.org/web/20140420105108/http://msdn.microsoft.com/en-us/library/ff469400.aspx | url-status = live }}</ref> The difference lies in whether CDXA extension space is used.<ref name=mkisofs/>

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-2|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:

* [[Microsoft Windows]];<ref name="mskb125630"/> Microsoft recommends the use of the Joliet extension for developers targeting Windows.<ref name="mskb125630"/>
* [[Linux]]<ref>{{cite web | title = Is Microsoft's Joliet filesystem supported? | work = The Linux CD-ROM HOWTO | version = Revision 1.17 | date = 18 July 2001 | author = Jeff Tranter | url = https://tldp.org/HOWTO/CDROM-HOWTO/x1186.html#AEN1328 | access-date = 2012-05-29 | archive-date = 8 August 2020 | archive-url = https://web.archive.org/web/20200808043704/https://www.tldp.org/HOWTO/CDROM-HOWTO/x1186.html#AEN1328 | url-status = live }}</ref>
* [[macOS]]<ref>{{cite web | title = hdiutil(1) | work = BSD General Commands Manual | publisher = Apple | date = 18 March 2011 | version = Mac OS X Version 10.7.4 | url = https://developer.apple.com/library/mac/#documentation/Darwin/Reference/ManPages/man1/hdiutil.1.html | access-date = 2012-05-29 | archive-date = 9 June 2012 | archive-url = https://web.archive.org/web/20120609170929/http://developer.apple.com/library/mac/#documentation/Darwin/Reference/ManPages/man1/hdiutil.1.html | url-status = live }}</ref>
* [[FreeBSD]]<ref>{{cite web | title = FreeBSD 3.2 Release Notes | publisher = The FreeBSD Project | url = http://www.freebsd.org/releases/3.2R/notes.html | access-date = 29 May 2012 | archive-date = 22 December 2018 | archive-url = https://web.archive.org/web/20181222001117/https://www.freebsd.org/releases/3.2R/notes.html | url-status = live }}</ref>
* [[OpenSolaris]]<ref>{{cite web | title = hsfs - High Sierra & ISO 9660 CD-ROM file system | work = OpenSolaris Man Page Set | date = 1 November 2006 | version = SunOS 5.11 / OpenSolaris 2009.06 | url = http://www.unix.com/man-page/OpenSolaris/7fs/hsfs/ | access-date = 2012-05-29 }}</ref>
* [[Haiku (operating system)|Haiku]]<ref>{{cite web | title = Haiku Source Tree, src/add-ons/kernel/file_systems/iso9660/iso9660.cpp | url = http://cgit.haiku-os.org/haiku/tree/src/add-ons/kernel/file_systems/iso9660/iso9660.cpp | access-date = 24 November 2020 | archive-date = 5 April 2023 | archive-url = https://web.archive.org/web/20230405093359/https://cgit.haiku-os.org/haiku/tree/src/add-ons/kernel/file_systems/iso9660/iso9660.cpp | url-status = live }}</ref>
* [[AmigaOS]]
* [[RISC OS]]<ref>{{cite web | title = Add support for Joliet format CD-ROMs hdr/Hashes s/Directory s/EntryFile s/FileMan s/Filer s/Free (999bdda6) · Commits · RiscOS / Sources / FileSys / CDFS / CDFS | date = 15 August 2013| url = https://gitlab.riscosopen.org/RiscOS/Sources/FileSys/CDFS/CDFS/-/commit/999bdda6c38c3fa78ff7e58bd1752c1052f8c247}}</ref>

=== Romeo ===

''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.<ref name="Romeo">{{cite web|url=http://support.apple.com/kb/TA21734?viewlocale=en_US|title=CD-ROM Discs: Joliet & Romeo Name Definitions|publisher=Apple Inc.|date=1 June 2007|access-date=2010-07-20|archive-date=14 March 2014|archive-url=https://web.archive.org/web/20140314132524/http://support.apple.com/kb/TA21734?viewlocale=en_US|url-status=live}}</ref> 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 ===

[[Apple Computer]] authored a set of extensions that add [[ProDOS]] or [[Hierarchical File System (Apple)|HFS]]/[[HFS Plus|HFS+]] (the primary contemporary file systems for the [[classic Mac OS]]) properties to the filesystem. Some of the additional metadata properties include:<ref>{{cite web |url = http://developer.apple.com/technotes/fl/fl_36.html |title = Technical Note FL36: Apple Extensions to ISO 9660 |archive-url=https://web.archive.org/web/20081226015418/http://developer.apple.com/technotes/fl/fl_36.html |archive-date=26 December 2008 |url-status=dead}}</ref>
* 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 system]]s that are able to read ISO 9660.

=== Other extensions ===

For operating systems which do not support any extensions, a name translation file <code>TRANS.TBL</code> must be used. The <code>TRANS.TBL</code> file is a plain [[ASCII]] text file. Each line contains three fields, separated by an arbitrary amount of [[Whitespace character|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 <code>TRANS.TBL</code> 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 [[Session (CD)|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 [[DVD]]s. The volume descriptor table retains the ISO9660 layout, but the identifier has been updated.<ref>{{cite web| url = http://www.ecma-international.org/publications/files/ECMA-ST/Ecma-167.pdf| title = ECMA-167 - Volume and File Structure for Write-Once and Rewritable Media using Non-Sequential Recording for Information Interchange| access-date = 30 April 2013| archive-date = 22 September 2020| archive-url = https://web.archive.org/web/20200922202706/http://www.ecma-international.org/publications/files/ECMA-ST/Ecma-167.pdf| url-status = live}}</ref><ref>{{cite web| url = http://www.standards.com/StandardsDownloads/birth.html| title = Birth Announcement: ISO/IEC 13346 and ISO/IEC 13490| access-date = 30 April 2013| archive-date = 19 February 2013| archive-url = https://web.archive.org/web/20130219062932/http://www.standards.com/StandardsDownloads/birth.html| url-status = live}}</ref>

== Disc images ==

[[Optical disc image]]s are a common way to electronically transfer the contents of CD-ROMs. They often have the [[filename extension]] <code>.iso</code> (<code>.iso9660</code> is less common, but also in use) and are commonly referred to as "ISOs".<ref>{{Cite web|last=Gavin|first=Brady|title=What Is An ISO File (And How Do I Use Them)?|url=https://www.howtogeek.com/356714/what-is-an-iso-file-and-how-do-i-open-one/|access-date=2021-12-23|website=How-To Geek|date=25 June 2018|language=en-US|archive-date=23 December 2021|archive-url=https://web.archive.org/web/20211223225020/https://www.howtogeek.com/356714/what-is-an-iso-file-and-how-do-i-open-one/|url-status=live}}</ref>

== Platforms ==

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:

* [[DOS]]: access with extensions, such as [[MSCDEX|MSCDEX.EXE]] (Microsoft CDROM Extension), [[NWCDEX|NWCDEX.EXE]] or CORELCDX.EXE
* Microsoft [[Windows 95]], [[Windows 98]], [[Windows ME]]: can read ISO 9660 Level 1, 2, 3, and [[Joliet (file system)|Joliet]]
* Microsoft [[Windows NT 4.0]], [[Windows 2000]], [[Windows XP]], and newer Windows versions, can read ISO 9660 Level 1, 2, 3, [[Joliet (file system)|Joliet]], and ISO 9660:1999. [[Windows 7]] may also mistake UDF format for CDFS. for more information see [[Universal Disc Format|UDF]].
* [[Linux]] and [[Berkeley Software Distribution|BSD]]: ISO 9660 Level 1, 2, 3, Joliet, [[Rock Ridge]], and ISO 9660:1999
* [[Apple GS/OS]]: ISO Level 1 and 2 support via the HS.FST File System Translator.<ref>{{cite web
| url=http://juiced.gs/wp-content/uploads/juicedv9i2.pdf
| title=The Virtual GS: Using ISO disk images in Apple II emulators
| publisher=Juiced.GS Volume 9, Issue 2
| date=May 2004
| access-date=27 May 2009
| archive-date=31 March 2010
| archive-url=https://web.archive.org/web/20100331151804/http://juiced.gs/wp-content/uploads/juicedv9i2.pdf
| url-status=live
}}</ref>
* [[Classic Mac OS]] 7 to 9: ISO Level 1, 2. Optional free software supports [[Rock Ridge]] and [[Joliet (file system)|Joliet]] (including ISO Level 3): [http://www.alex-castro.com/jokeridge/ Joke Ridge] and [http://www.tempel.org/joliet/ Joliet Volume Access].
* [[macOS]] (all versions): ISO Level 1, 2, [[Joliet (file system)|Joliet]] and [[Rock Ridge]] Extensions. Level 3 is not currently supported, although users have been able to mount these discs<ref>{{cite web|url=http://hints.macworld.com/article.php?story=2004041301593855|title=Work with PC-created Joliet Level 3 CDs|date=16 April 2004|access-date=10 December 2017|archive-date=6 September 2015|archive-url=https://web.archive.org/web/20150906114242/http://hints.macworld.com/article.php?story=2004041301593855|url-status=dead}}</ref>
* [[AmigaOS]] supports the "AS" extensions (which preserve the Amiga protection bits and file comments)
* [[QNX]]
* [[ULTRIX]]
* [[OS/2]], [[eComStation]] and [[ArcaOS]]
* [[BeOS]], [[Zeta (operating system)|Zeta]] and [[Haiku (operating system)|Haiku]]
* [[OpenVMS]] supports only ISO 9660 Interchange levels 1–3, with ''no'' extensions<ref>{{Cite web|publisher=Hoffman Labs|title=The OpenVMS Frequently Asked Questions (FAQs)|url=http://hoffmanlabs.org/vmsfaq/vmsfaq_014.html#index_x_893|access-date=1 September 2011|archive-date=19 November 2017|archive-url=https://web.archive.org/web/20171119173826/http://hoffmanlabs.org/vmsfaq/vmsfaq_014.html#index_x_893|url-status=dead}}</ref>
* [[RISC OS]] support for optical media written on a PC is patchy. Most CD-Rs/RWs work perfectly, however DVD+-Rs/RWs/RAMs are entirely hit and miss running RISC OS 4.02, RISC OS 4.39 and RISC OS 6.20{{Citation needed|date=December 2017}}

== See also ==

* [[Comparison of disc image software]]
* [[Disk image emulator]]
* [[List of ISO standards]]
* [[Hybrid CD]]
* [[ISO/IEC JTC 1/SC 23]]

== References ==

{{reflist}}

== Further reading ==

* {{ cite book |author-first1=Harold |author-last1=Evans |author-link1=Harold Evans |author-first2=Gail |author-last2=Buckland |author-first3=David |author-last3=Lefer |author-link3=David Lefer |year=2004 |title=They Made America: From the Steam Engine to the Search Engine: Two Centuries of Innovators |publisher=[[Little, Brown and Co.]] |isbn=978-0-316-27766-2 |url-access=registration |url=https://archive.org/details/theymadeamericaf00evan }}
* {{ cite book |title=CD ROM - The New Papyrus: The current and future state of the art |editor-first1=Steve |editor-last1=Lambert |editor-first2=Suzanne |editor-last2=Ropiequet |publisher=[[Microsoft Press]] |date=1986 |isbn=0-914845-74-8 |url=https://archive.org/details/cdrom00lamb |url-access=registration }}

== External links ==

* {{cite web|url=http://www.iso.org/iso/en/CatalogueDetailPage.CatalogueDetail?CSNUMBER=17505&ICS1=35&ICS2=220&ICS3=30|title=ISO 9660}}
* {{cite web|url=http://www.ecma-international.org/publications/standards/Ecma-119.htm|title=ECMA-119}} This is the ECMA release of the ISO 9660:1988 standard, available as a free download
* {{cite web |url=http://users.pandora.be/it3.consultants.bvba/handouts/ISO9960.html |url-status=dead |archive-url=https://web.archive.org/web/20220527031632/http://users.telenet.be/it3.consultants.bvba/handouts/ISO9960.html |archive-date=27 May 2022 |title=Summary of the ISO 9660 Specifications}}
* {{cite web|url=http://alumnus.caltech.edu/~pje/iso9660.html|title=Description of data structures in ISO-9660|archive-url=https://web.archive.org/web/20110717142714/http://alumnus.caltech.edu/~pje/iso9660.html|archive-date=17 July 2011}}
* {{Freshmeat|iat|ISO 9660 Analyzer Tool (iat)}}
* {{cite web|url=http://www.ymi.com/ymi/node/5|title=RRIP History: About Young Minds, Inc.|archive-url=https://web.archive.org/web/20180317214944/http://www.ymi.com/ymi/node/5|archive-date=17 March 2018}}
* {{cite web|url=http://www.ymi.com/ymi/sites/default/files/pdf/Systems%20Use%20P1281.pdf|title=SUSP (IEEE P1281) Draft Standard 1.12|date=8 July 1994|archive-url=https://web.archive.org/web/20170404132301/http://www.ymi.com/ymi/sites/default/files/pdf/Systems%20Use%20P1281.pdf|archive-date=2017-04-04|url-status=dead}}
* {{cite web|url=http://www.ymi.com/ymi/sites/default/files/pdf/Rockridge.pdf|title=RRIP (IEEE P1282) Draft Standard 1.12|date=8 July 1994|archive-url=https://web.archive.org/web/20170404043745/http://www.ymi.com/ymi/sites/default/files/pdf/Rockridge.pdf|archive-date=2017-04-04|url-status=dead}}
* {{cite web|url=http://www.estamos.de/makecd/Rock_Ridge_Amiga_Specific|title=Amiga Extensions on Rock Ridge: "Documents related to MakeCD program"|date=5 December 1996}}
* {{ cite web | archive-url = https://web.archive.org/web/20080218195330/http://download.intel.com/support/motherboards/desktop/sb/specscdrom.pdf | archive-date = 18 February 2008 | title = The "El Torito" Bootable CD-ROM Format Specification, Version 1.0 | url = http://download.intel.com/support/motherboards/desktop/sb/specscdrom.pdf }}
* [https://archive.today/20130415092739/http://www.kernel.org/git/?p=boot/syslinux/syslinux.git;a=blob;hb=HEAD;f=core/isolinux.asm ISOLINUX source code] (see isolinux.asm line 294 onward)
* {{cite web|url=https://www.cs.cmu.edu/afs/cs.cmu.edu/user/ralf/pub/WWW/files.html|title=Ralf Brown's interrupt list}} (see int 13h in interrupt.b, esp. functions 4a to 4d)
* {{cite web|url=http://littlesvr.ca/isomaster/eltoritosuppl.php|title=EL Torito Specification Supplement}}, discusses shortcomings of the standard
* [https://patents.google.com/patent/US5758352 US Patent 5758352 - Common name space for long and short filenames]
* {{cite web|url=http://www.pismotechnic.com/cfs/jolspec.html|title=Joliet Specification}}

{{File systems}}
{{Ecma International Standards}}
{{ISO standards}}

[[Category:Amiga APIs]]
[[Category:Apple Inc. file systems]]
[[Category:Compact disc]]
[[Category:Disk file systems]]
[[Category:Ecma standards]]
[[Category:ISO standards|#09660]]
[[Category:Optical computer storage]]
[[Category:Optical disc authoring]]
[[Category:Windows disk file systems]]