Editing ISO 9660 (section)

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

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}}</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 }}</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]] ({{CoordDec|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 | 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}}</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 }}</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 }}</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 }}</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 }}</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 }}</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 }}</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 }}</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 }}</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 }}</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}}</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}}</ref><ref>{{cite web| url = http://www.standards.com/StandardsDownloads/birth.html| title = Birth Announcement: ISO/IEC 13346 and ISO/IEC 13490}}</ref>