LEGACY NOTE · PERIOD DOCUMENT, 2009

Disc images as an archiving format, 2009

The page at this address in 2009 was promotional copy for a disc-copying product. What is worth recording instead is the archival idea underneath it: why people made disc images at all, and what replaced the practice.

Published 2026-08-06 · Updated — · 2,208 words · 15 sources · Status of facts checked 2026-08-06

In June 2009 this path carried a post inside a user blog on the social bookmarking community that then occupied this domain. Its body was promotional copy for a commercial Mac disc-copying application, and none of it is reproduced here. Two Wayback captures of the path return HTTP 200, dated 2009-06-13 and 2009-06-16.³

This page describes historical practice from 2007–2010 and is not current advice.

Copying commercial discs that carry access controls is a separate legal question. This publication does not cover it, takes no position on it, and gives no instructions for it.

What is on subject at this address is not the product but the format it produced. A disc image was one of the few consumer-legible ways to hold a complete artefact rather than a pointer to one, which is the same distinction the rest of this publication applies to saved links. The format outlived the practice, and the practice outlived the discs.

What an ISO image is, as a data structure

The governing specification is ECMA-119, Volume and file structure of CD-ROM for information interchange, issued in a first edition in December 1986 and a second in December 1987, and carrying the ISO number 9660. It is not a frozen document: Ecma International lists a third edition in December 2017, a fourth in June 2019, a fifth in December 2024 and a sixth in December 2025.¹

The layout is short enough to state in full. A volume is organised into logical sectors of 2,048 bytes, or of the largest power of two that does not exceed the medium’s own sector size, whichever is larger. Logical sectors 0 to 15 are the system area, reserved for system use, and the standard does not specify its content. Volume descriptors are recorded in consecutively numbered logical sectors starting with logical sector 16, and every descriptor carries a standard identifier in byte positions 2 to 6 whose characters, in the standard’s own wording, shall be CD001. Sixteen sectors of 2,048 bytes is 32,768, so the descriptor type byte sits at offset 32768 and those five identifier bytes begin at 32769.¹

That arithmetic is checkable against any image a reader already holds. The Library of Congress records the same signature as the ASCII string CD001, citing Gary Kessler’s file-signature table for the observation that it usually occurs at byte offset 32769, 34817 or 36865.² A range request for the first 48 KB of debian-13.6.0-amd64-netinst.iso, as published in the current Debian amd64 netinst directory, returns 0x01 at offset 32768, CD001 at 32769, three further CD001 identifiers at 34817, 36865 and 38913, and the volume identifier Debian 13.6.0 amd64 n in the 32-byte field at offset 32808 (checked 2026-08-06).⁴ A structure specified in 1986 is still the first thing inside a file distributed today.

The constraint people remember lives in the levels of interchange. At level 1 a file name may not exceed eight characters and its extension three.¹ That limit is why the format grew a shelf of extensions rather than a successor: Rock Ridge for POSIX permissions and long names, Microsoft’s Joliet for Unicode names, El Torito for booting PCs, and Apple’s own ISO 9660 extensions. The Library of Congress states the consequence plainly: there is no comprehensive single specification for all the variant formats called an ISO image, and tools and operating systems offer varying support for the extensions.² A file named after a standard is not a promise that one standard describes it.

Why the copies were made at all

Two properties explain the period. The first is completeness: an image contains the data contents of every written sector of the disc, including the disc’s file system where one is present, which makes it a medium-independent version of a medium-dependent object.² The second is that a single file has a single checksum, so the question “is this still the same thing” has an answer that a copied folder of loose files does not have.

The economics were not sentimental. A single-layer recordable DVD held 4.7 GB.⁵ The network alternative can be dated precisely: the Federal Communications Commission’s National Broadband Plan, sent to Congress 2010-03-16, set a National Broadband Availability Target of “actual download speeds of at least 4 Mbps and actual upload speeds of at least 1 Mbps” — listed in the same document as a 2020 universalisation target, not as a description of what households had in 2010.⁶ At one megabit per second upstream, moving 4.7 GB is roughly ten hours of uninterrupted transfer.^a Measured against the rate a federal plan was still setting as a target for 2020, a remote copy of a full disc was a ten-hour operation rather than a background one.

The same season, one directory up

While this address was describing a disc-copying tool, the subject the domain actually indexed was demonstrating the other half of the lesson. Ma.gnolia’s database and file system failed on 2009-01-30, and founder Larry Halff announced on 2009-02-17 that user data was irretrievable. Backblaze’s account, published 2009-03-02, states that the service’s backup was a file sync over FireWire to another computer with no integrity checking, no versioning and no test of whether the backups worked — and that when it came time to restore, they did not.⁷

The rule that joins the two pages on this domain is short: a copy nobody has ever read back is a claim, not a copy. A disc image happened to make that claim testable, because a checksum over one file is a complete test of it. A file sync without integrity checking makes the same promise and cannot be tested until the day the test matters.

What the discs actually did

The life expectancies claimed for optical media at the time were long, and largely untested. The guide by Fred R. Byers published in October 2003 by the National Institute of Standards and Technology and the Council on Library and Information Resources records a consensus among manufacturers that had done testing that CD-R, DVD-R and DVD+R discs “should have a life expectancy of 100 to 200 years or more” under recommended storage conditions, and that CD-RW, DVD-RW, DVD+RW and DVD-RAM discs “should have a life expectancy of 25 years or more” — followed immediately by the observation that “few, if any, life expectancy reports for these discs have been published by independent laboratories.”⁵

Independent numbers arrived in the NIST and Library of Congress Optical Disc Longevity Study, final report dated September 2007, run on media acquired in 2005, ninety samples per product, aged artificially against the Eyring model. Of fifteen recordable and rewritable DVD products tested, seven had estimated life expectancies in ambient conditions of more than 45 years, four fell in the 30-to-45-year band, two in the 15-to-30-year band, and two came in under 15 years. Of seven CD-R products tested, five exceeded 45 years and the remaining two fell in the 30-to-45-year band.⁸

The spread is the finding, not the top figure. Two DVD products out of fifteen, sold in the same years for the same purpose, were estimated to fail inside fifteen years, and a buyer holding a spindle had no published way to tell which product was in hand — the report names no brands, by design. The question a disc could answer at the moment of writing was whether it burned; the question that decided whether the copy survived was whether that particular disc was still readable years later, and what would say so before the day it was needed.

The surviving half of the idea

What carried forward from disc archiving is not the disc. It is fixity: a checksum recorded when the copy is made and checked again later, on a schedule rather than in a panic. The National Digital Stewardship Alliance’s 2014 guidance is built around that framing, its stated question being not whether stewards should check fixity but how, when and how often.⁹

As of 2026-08-06, and stated as rules about a reader’s own files rather than as instructions for anybody else’s media:

• A copy whose checksum was never recorded at the moment it was made cannot later be distinguished from a copy that has decayed; a record of that checksum, held somewhere other than beside the copy, is what makes the distinction possible.
• A copy that is only ever read at the moment it is needed is tested for the first time on the worst available day; a scheduled re-read compared against the recorded checksum moves that test forward.
• A single copy has the lifespan of whatever holds it, and two copies that share one device, one medium or one account have one lifespan between them.

Where the format sits in 2026

The format is in service, and what keeps it there is the 2009 property. Debian publishes signed checksum files beside its images and documents verifying them: SHA256 and SHA512 checksums, checked with sha256sum or sha512sum, and the checksum files themselves verified against accompanying signature files with an OpenPGP implementation.¹⁰ The current amd64 netinst directory carried SHA256SUMS, SHA256SUMS.sign, SHA512SUMS and SHA512SUMS.sign when checked 2026-08-06.⁴ A complete artefact plus a published checksum is the entire idea, still running.

Institutionally, the Library of Congress records the format as the master file format used for the preservation reformatting of physical discs in its Tangible Media Project, beginning in 2011, and as the preservation master format for write-once DVDs of oral histories received by the Veterans History Project. The same description carries the limit: ISO disk image files “support the important goal of bit preservation but not long-term content management.”² The bytes are safe; whether anything can still open them is a different question with a different answer.

The hardware went first. Apple’s MacBook Air, announced 2008-01-15, shipped without a built-in optical drive, with a $99 external SuperDrive and access to the optical drives of remote Macs and PCs named as the alternatives.¹¹ The trail in Apple’s own documentation is dated: the table of contents of the Disk Utility User Guide for macOS Tahoe 26 lists no topic on burning a disc, and the guide’s single mention of burning points the reader at the Finder instead. Disk Utility still creates a DVD/CD master image with a .cdr extension, and a hybrid HFS+/ISO/UDF image (checked 2026-08-06).¹² The image formats outlived the drives.

What took the practice’s place

Two things did, at two scales. Institutionally the container is WARC, standardised as ISO 28500, second edition 2017-08, whose scope is to store both the payload content and the control information of mainstream internet application-layer protocol transactions rather than the contents of a physical volume.¹³¹⁴ Individually the equivalent gesture is one self-contained file per page: SingleFile, AGPL-3.0, repository created 2010-09-12, 22,101 stars, last pushed 2026-08-05, saves a complete page into a single HTML file (checked 2026-08-06).¹⁵

Stated as a rule rather than as advice: a collection that must answer “what did this actually contain” after the source is gone requires stored bytes and a recorded checksum over them; a collection that only needs to be re-findable requires neither and should not pay for them. Disc images answered the first question for one class of artefact for about a decade, and answered nothing at all for the web — which is why the 2009 page at this address is a period document while the idea underneath it is not.^b

References

1. Ecma International. “ECMA-119: Volume and file structure of CD-ROM for information interchange, 6th edition.” Ecma International, 2025-12. https://ecma-international.org/publications-and-standards/standards/ecma-119/ — retrieved 2026-08-06. ↩
2. Library of Congress. “ISO Disk Image File Format.” Sustainability of Digital Formats, 2012-08-01. https://www.loc.gov/preservation/digital/formats/fdd/fdd000348.shtml — retrieved 2026-08-06. ↩
3. Internet Archive. “Wayback CDX Server API query for infopirate.org/_how-burn-dvd-iso-file-mac.” Internet Archive, n.d. http://web.archive.org/cdx/search/cdx?url=infopirate.org/_how-burn-dvd-iso-file-mac&fl=timestamp,statuscode,original — retrieved 2026-08-06. ↩
4. Debian Project. “Index of /debian-cd/current/amd64/iso-cd/.” cdimage.debian.org, n.d. https://cdimage.debian.org/debian-cd/current/amd64/iso-cd/ — retrieved 2026-08-06. ↩
5. Byers, Fred R. “Care and Handling of CDs and DVDs: A Guide for Librarians and Archivists.” Council on Library and Information Resources and National Institute of Standards and Technology (NIST Special Publication 500-252), 2003-10. https://www.clir.org/wp-content/uploads/sites/6/pub121.pdf — retrieved 2026-08-06. ↩
6. Federal Communications Commission. “Connecting America: The National Broadband Plan.” FCC, 2010-03-16. https://transition.fcc.gov/national-broadband-plan/national-broadband-plan.pdf — retrieved 2026-08-06. ↩
7. Budman, Gleb. “Ma.gnolia Wilts with No Backup.” Backblaze, 2009-03-02. https://www.backblaze.com/blog/magnolia-wilts-with-no-backup/ — retrieved 2026-08-06. ↩
8. Zheng, J., O. Slattery, F. Byers, A. Klepchukov, A. Nhan, C. Shahani, M. Youket, E. Eusman and N. Olson. “Final Report: NIST/Library of Congress (LC) Optical Disc Longevity Study.” NIST and Library of Congress, 2007-09. https://www.loc.gov/preservation/resources/rt/NIST_LC_OpticalDiscLongevity.pdf — retrieved 2026-08-06. ↩
9. De Stefano, Paula, Carl Fleischhauer, Andrea Goethals, et al. “Checking Your Digital Content: What is Fixity, and When Should I be Checking It?” National Digital Stewardship Alliance, 2014. https://www.ndsa.org/documents/NDSA-Fixity-Guidance-Report-final100214.pdf — retrieved 2026-08-06. ↩
10. Debian Project. “Verifying authenticity of Debian images.” debian.org, n.d. https://www.debian.org/CD/verify — retrieved 2026-08-06. ↩
11. Apple. “Apple Introduces MacBook Air — The World’s Thinnest Notebook.” Apple Newsroom, 2008-01-15. https://www.apple.com/newsroom/2008/01/15Apple-Introduces-MacBook-Air-The-Worlds-Thinnest-Notebook/ — retrieved 2026-08-06. ↩
12. Apple. “Create a disk image using Disk Utility on Mac.” Disk Utility User Guide for macOS Tahoe 26, n.d. https://support.apple.com/guide/disk-utility/create-a-disk-image-dskutl11888/mac — retrieved 2026-08-06. ↩
13. International Organization for Standardization. “ISO 28500:2017 Information and documentation — WARC file format.” ISO, 2017-08. https://www.iso.org/standard/68004.html — retrieved 2026-08-06. ↩
14. International Internet Preservation Consortium. “The WARC Format 1.1.” IIPC WARC Specifications, n.d. https://iipc.github.io/warc-specifications/specifications/warc-format/warc-1.1/ — retrieved 2026-08-06. ↩
15. Lormeau, Gildas. “SingleFile.” GitHub, n.d. https://github.com/gildas-lormeau/SingleFile — retrieved 2026-08-06. ↩

Notes

1. 4.7 × 10⁹ bytes is 3.76 × 10¹⁰ bits; at 10⁶ bits per second that is 37,600 seconds, or about 10.4 hours, before any protocol overhead or contention. The figure is arithmetic on the cited capacity and the cited target rate, not a measurement of anything. ↩
2. The eight-character name limit at level 1 of interchange is why so much period software wrote file names in capitals with three-letter extensions, and why a disc that looked correct under one operating system could show truncated names under another: the long names lived in an extension the reading system might not implement. ↩

From about 2007 to about 2010 this address belonged to a Drupal-based social bookmarking community, and in June 2009 this particular path held a post inside one of that community’s user blogs, promoting a commercial Mac disc-copying application. Captures of the path returning HTTP 200 stop after 2009-06-16; from 2012-05-20 the apex answers 404, a single 2016-03-11 capture returns a domain-parking page, and the last capture of any kind is a 404 dated 2025-06-30. Two pages elsewhere still point at this address: a reader comment on a Microsoft Learn documentation page, and a post on the openSUSE Lizards blog (checked 2026-08-06). Neither is Microsoft’s or openSUSE’s editorial voice.