Fact-checked by Grok 2 weeks ago

Hierarchical File System

The Hierarchical File System (HFS) is a proprietary file system developed by Apple Inc. for use on Macintosh computers, introduced in 1985 to provide a tree-like structure for organizing files and directories on storage volumes such as hard disks and floppy disks.^[1] HFS replaced the earlier flat Macintosh File System (MFS), which lacked directories and organized all files at the root level, by introducing a hierarchical directory structure managed through a catalog file implemented as a B-tree for efficient searching and maintenance.^[2] Key components include volumes (logical storage units up to 2 GB in early versions), files with separate data forks for user content and resource forks for application resources like icons and menus, and allocation blocks (minimum 512 bytes) to manage free space via a bitmap.^[3] Filenames were limited to 31 characters (case-insensitive, using Macintosh Roman encoding), and the system supported up to 65,536 files per volume and 32,767 per directory, with a maximum file size of 2 GB.^[3] While innovative for its time, HFS had limitations such as inefficient handling of large volumes, no native support for long filenames or Unicode, and vulnerability to fragmentation due to its fixed allocation block sizes, which increased the minimum file size on larger drives (e.g., 32 KB on a 2 GB volume).^[3] It served as the standard file system for Mac OS until 1998, when Apple released HFS Plus (also known as Mac OS Extended), an enhanced version that supported volumes up to 8 exabytes, Unicode filenames up to 255 characters, and journaling for better reliability.^[4] HFS Plus remained the default until 2017, when it was succeeded by the Apple File System (APFS) for modern features like snapshots and encryption, though HFS and HFS Plus are still supported for compatibility in current macOS versions.^[5]

History

Development

The development of the Hierarchical File System (HFS) began in 1985 at Apple Computer, Inc., led by engineers Patrick Dirks and Bill Bruffey, as a direct response to the limitations of the original Macintosh File System (MFS). MFS, introduced with the Macintosh in 1984, employed a flat structure that restricted files to a single level without subdirectories, making it inadequate for organizing the increasing volumes of data on emerging hard disk drives. This flat design resulted in inefficient serial searches across all files, which became problematic as storage capacities grew beyond the 400 KB limits of early floppy disks.^[6] The primary motivation for HFS was to introduce a tree-structured directory system capable of handling larger storage media, such as the 20 MB hard drives becoming available for personal computers. This hierarchical approach allowed for nested folders, enabling better organization and scalability for users dealing with thousands of files in professional or small business environments. While drawing conceptual inspiration from the hierarchical directories in Unix-like systems, HFS was specifically tailored to integrate seamlessly with the Macintosh's graphical user interface, emphasizing intuitive folder icons and drag-and-drop navigation rather than command-line operations.^[7]^[6] Prototyping of HFS commenced in the early months of 1985, with the system undergoing rapid iteration to ensure compatibility with Apple's hardware constraints, including slower processors and limited RAM. By mid-1985, the core architecture was finalized, incorporating innovative data structures to optimize performance on these resource-limited machines. A key decision during this phase was the adoption of B-trees for the catalog and extent allocation, selected for their ability to maintain balanced trees that support efficient logarithmic-time searches, insertions, and deletions in ascending key order—critical for quick file retrieval without exhaustive scans. This choice prioritized reliability and speed over simpler alternatives, as B-trees automatically handle node splitting and rotation to preserve balance, making them suitable for the variable-sized records in a hierarchical catalog.^[7] HFS was completed in time for its debut alongside Apple's first Macintosh hard drive, the 20 MB HD20, which launched on September 17, 1985. The HD20, priced at $1,499, marked the transition from floppy-based storage to more robust hard disk solutions, and HFS's design directly addressed the need for efficient management of such larger volumes. The system's patent, filed on October 30, 1986, and granted on July 31, 1990, credits Dirks, Bruffey, and additional contributors for the foundational elements that enabled this advancement in personal computing file management.^[8]^[7]

Introduction and Adoption

The Hierarchical File System (HFS) was officially introduced by Apple in September 1985 alongside System Software 2.1, primarily to enable support for the Macintosh Hard Disk 20, Apple's inaugural 20 MB external hard drive that connected via the Macintosh's floppy port.^[9]^[8] Developed by Apple engineers Patrick Dirks and Bill Bruffey, HFS replaced the flat Macintosh File System (MFS) with a true hierarchical directory structure, allowing nested folders to better organize growing volumes of data on larger storage media.^[6] HFS gained prominence with its bundling in the Macintosh Plus computer and System Software 3.0, released on January 16, 1986, which established it as the default file system for hard drives in the Macintosh lineup.^[10]^[11] This integration extended to high-capacity floppy disks, where 400K single-sided and 800K double-sided disks could be initialized as HFS volumes using Apple's Disk Initialization utility, enabling users to create structured directories on removable media.^[12] Support for HFS was embedded directly in the 128 KB ROM of the Macintosh Plus and all subsequent models, ensuring native hardware-level compatibility without requiring additional software for basic operations.^[13] Adoption accelerated rapidly among professional Macintosh users by 1987, driven by the increasing availability of affordable hard drives and the system's suitability for desktop publishing and creative workflows, with HFS becoming the standard format for nearly all new Macintosh hard drives and 800K floppies thereafter.^[14] By 1988, the majority of shipped Macintosh systems included HFS-formatted storage as default, reflecting its widespread acceptance in business and creative environments.^[15] HFS also extended to optical media, serving as the foundation for the High Sierra format introduced in 1986 and implemented in Apple's first CD-ROM drive announced in March 1988, which facilitated data distribution on read-only discs for Macintosh applications.^[16]^[17] Initial rollout presented challenges for users transitioning from MFS's flat structure, including confusion over folder navigation and organization in the Finder interface.^[6] These issues were mitigated through enhancements in System 4.0, released in January 1987, which refined Finder 5.4's handling of hierarchical views, improved directory browsing, and added better support for larger volumes exceeding 32 MB.^[18]^[10]

Design and Architecture

Volume Format

The Hierarchical File System (HFS) organizes data on a volume using fixed-size logical blocks of 512 bytes each, which form the fundamental unit of disk storage. These logical blocks are aggregated into allocation blocks for efficient space management, with allocation block sizes typically ranging from 0.5 KB to 16 KB based on the overall volume capacity; the system supports a maximum of 65,535 allocation blocks per volume to balance fragmentation and overhead.^[19] The volume begins with two Boot Blocks in logical blocks 0 and 1, which store bootstrap code and system startup information required to mount and boot from the volume.^[19] Immediately following, the Master Directory Block (MDB) occupies block 2 and serves as the primary metadata structure, containing the volume signature (0x4244, representing "BD"), the creation date and time, the last modification date, volume attributes, and the total count of allocation blocks.^[19] The MDB also records the number of free allocation blocks, the default clump size for file extents, and initial extent records for key system files like the catalog and extents overflow files.^[19] Starting at block 3, the Volume Bitmap follows the MDB and allocates space to track the usage of allocation blocks across the volume, using one bit per block (0 for free, 1 for allocated), with the bitmap's size scaling to accommodate up to 65,535 blocks (maximum 8,192 bytes).^[19] This structure enables quick queries for available space during file operations. File mapping to physical storage is managed via extent allocation, where non-contiguous data portions (extents) are recorded in the extents overflow file, organized as a B-tree for efficient lookups.^[19] HFS volumes have a theoretical maximum capacity of 2 TiB in later implementations, though early implementations capped practical sizes at 2 GB due to software constraints.^[3] The allocation block size is calculated during formatting as the total number of logical blocks divided by 65,535 (rounded up), ensuring the limit is not exceeded while optimizing for the volume's scale—for instance, a 10 MB volume might use 512-byte blocks, while larger ones employ progressively bigger units up to 16 KB.^[19] Volumes are initialized through the Disk Initialization utility (or equivalent formatting tools in the Macintosh operating system), which computes and sets the allocation block size, populates the MDB with initial metadata (marking all blocks as free except reserved areas), clears the Volume Bitmap to indicate full availability, and creates the essential special files for catalog and extents management.^[19] This process ensures the volume is immediately mountable and ready for hierarchical file organization.^[3]

File and Directory Organization

In the Hierarchical File System (HFS), files and directories are organized into a tree-like hierarchy, with the root directory (assigned Catalog Node ID or CNID 2) at the top level containing all top-level items. Subdirectories function as specialized files, each with its own unique CNID, and parent-child relationships are established through dedicated thread records stored in the Catalog File; a directory thread record links a subdirectory to its parent by specifying the parent's CNID and the subdirectory's name, while a file thread record performs a similar linkage for files.^[19]^[20] Each file and directory entry resides in the Catalog File as a record within a B*-tree structure, capturing essential metadata including creation date, modification date, and backup date (all stored as long date-time values). File records additionally include type and creator codes—four-byte OSType identifiers that allow applications to identify and handle specific file formats, such as 'TEXT' for plain text or 'MACS' for Macintosh System files—and Finder flags, a 16-bit field where bits indicate attributes like bit 0 for locked status (preventing modifications) or bit 7 for invisibility (hiding from the Finder). Directory records mirror this structure but include a valence field tracking the number of contained items instead of fork details.^[19]^[20] Path resolution and navigation begin at the root directory and proceed by constructing search keys from parent CNIDs and component names, enabling threaded B-tree traversals through the Catalog File to locate entries efficiently; this supports operations like opening files via full or partial paths delimited by colons (e.g., 'Volume:Folder:File'). The system imposes no explicit limit on nesting depth, though the 255-character maximum pathname length practically restricts it to about eight levels when using maximum 31-character names per component.^[19]^[20] All metadata for files and directories, excluding the actual data content, is centralized in the Catalog File records, while file data itself is stored in separate extents—contiguous or non-contiguous allocation blocks tracked within the records and managed by the Volume Bitmap File for free space allocation; HFS lacks journaling, relying instead on manual consistency checks during volume mounting.^[19]

B-tree Structures

The Hierarchical File System (HFS) employs B-tree structures as balanced search trees to efficiently manage and index file system metadata, specifically in the Catalog File for storing records of files and directories, and in the Extents Overflow File for handling additional allocation extents beyond the initial eight per file. These B-trees are variants known as B*-trees, featuring nodes of a fixed 512-byte size to align with the underlying block structure of HFS volumes. The trees maintain balance, with index nodes supporting up to 15 child pointers (and thus multiple keys, typically 14 maximum), ensuring a low height for rapid access even on large volumes.^[21] B-tree nodes in HFS are categorized into distinct types to support navigation and data storage. The header node, typically located at block 0 of the B-tree file, records essential metadata including the total number of blocks in the tree, the current depth (height), and allocation maps for up to 2048 nodes, with additional map nodes extending support for larger trees. Index and map nodes serve navigational purposes, storing sorted keys along with pointers (2 bytes each) to child nodes, enabling hierarchical traversal; leaf nodes, in contrast, hold the actual data records without further children. For the Catalog File, each key comprises a parent directory ID (2 bytes) followed by the file or directory name as a Pascal string (up to 31 characters in MacRoman encoding), while the associated value is a fixed-size record detailing attributes like creation date, size, and location; the Extents Overflow File uses keys combining file type, ID, and the index of the first additional extent. Name comparisons are case-insensitive but case-preserving, relying on MacRoman encoding without native Unicode support.^[21] Operations on HFS B-trees follow a standard traversal-based search algorithm, starting from the root node and descending through index nodes by performing binary searches on the sorted keys to select the correct child pointer, until reaching the target leaf node where the key is matched or the insertion/deletion point is identified. To preserve balance during insertions or deletions, nodes that exceed the maximum key limit are split, and underfilled nodes (below the minimum keys) are merged or redistributed with siblings, propagating changes upward as needed. This design yields logarithmic time complexity, O(log n), for searches, insertions, and deletions relative to the number of records. Structural constraints, including the 512-byte node size and a maximum tree depth of 8 levels, limit the Catalog File to a maximum of 65,535 records, beyond which volume capacity is effectively capped.^[21]

Features

Data and Resource Forks

The Hierarchical File System (HFS) employs a dual-fork architecture for files, where each file consists of a data fork and a resource fork, both of which can be empty or contain data up to their respective limits (2 GB for the data fork and 16 MB for the resource fork), subject to the volume's capacity. The data fork holds the primary, unstructured content of the file, such as the text of a document or raw binary data, treated as a simple stream of bytes accessible via standard file I/O operations. In contrast, the resource fork stores structured elements organized into discrete resources, each identified by a four-character type (e.g., 'PICT' for bitmap images or 'MENU' for menu definitions) and a unique integer ID, allowing for modular management of ancillary file components like icons, dialog boxes, and sound data. Both forks share the same allocation bitmap on the HFS volume, meaning blocks are allocated from the common free space pool without distinction between fork types.^[22]^[3] Resources within the resource fork are managed through the Resource Manager API, a component of the Macintosh Toolbox that provides functions for loading, editing, and saving resources without directly manipulating the underlying fork data. This API organizes resources into a resource map—a hierarchical index within the fork that supports searching by type and ID—though it imposes practical limits, such as supporting up to approximately 2,700 resources per fork due to indexing constraints. Access to resources is abstracted, enabling applications to treat them as relocatable code or data segments that can be dynamically loaded into memory.^[22]^[23] This fork model was essential for Macintosh applications, as it separated editable, application-specific resources from the core data, facilitating updates to user interface elements or code without corrupting the primary content—for instance, system files often stored executable code segments in the resource fork to allow for easy patching or localization. In word processing applications, the data fork might contain the document's text, while the resource fork could hold custom styles or embedded images as 'PICT' resources, enabling seamless integration with the system's graphical environment. Type and creator codes, stored in the file's catalog entry, further associate resources with specific applications for proper handling upon file opening.^[22]^[23] File handling tools like ResEdit, developed by Apple, allow developers to visually edit and inspect resource forks, supporting operations such as adding, modifying, or extracting resources like 'MENU' definitions without altering the data fork. A file can have an empty resource fork, which is common for plain text documents, yet the structure is preserved in the catalog to maintain compatibility with applications expecting potential resources.^[24]^[22]

File Naming and Attributes

In the Hierarchical File System (HFS), file names are limited to a maximum length of 31 characters, stored as Pascal strings in the catalog records.^[2] These names use the MacRoman character encoding (or the active script system's encoding) and support diacritical marks, but the file system performs comparisons in a case-insensitive manner while preserving the original case in storage.^[2] Invalid characters are restricted to prevent structural issues, with the colon (:) explicitly prohibited as it serves as the path separator; other non-printing or control characters are discouraged to ensure compatibility with the Finder and applications.^[2] No names are reserved beyond the implicit handling of directory hierarchies, though names must be unique within a given directory to avoid conflicts during lookups.^[20] File attributes in HFS are stored in the catalog file's file descriptor records and include metadata for identification, protection, and Finder behavior. A 16-bit finder flags field (fdFlags in the FInfo structure) controls various properties, such as bit 7 (kIsLocked, 0x0080) which prevents modifications when set, and bit 14 (kIsInvisible, 0x4000) which hides the file from the Finder and standard file dialogs.^[25] Additional bits include bit 5 (kIsBundle, 0x0020) for application bundles and bit 4 (kIsSystem, 0x0010) for system files requiring elevated privileges.^[25] The type code (fdType, a 4-character OSType such as 'TEXT' for plain text files) and creator code (fdCreator, such as 'ttxt' for the default text editor) specify the file's content type and the application intended to open it by default.^[19] Permissions in HFS are basic and managed through flags rather than access control lists (ACLs), with the locked flag providing write protection and no granular user/group distinctions.^[20] Timestamps for creation, modification, and backup are recorded as 32-bit unsigned integers representing seconds elapsed since January 1, 1904, 00:00:00 GMT, relative to the Master Directory Block (MDB) for volume-specific adjustments.^[20] Internally, files are referenced by a unique 16-bit file ID (filFlNum) assigned upon creation, ensuring persistent identification independent of name changes or moves within the volume.^[20]

Limitations

Capacity and Performance Constraints

The Hierarchical File System (HFS) features inherent capacity limits stemming from its 16-bit addressing scheme for allocation blocks, which caps the total number of such blocks at 65,536 per volume. This restricts the maximum number of files and directories to 65,536, as each requires at least one catalog entry. Furthermore, individual files are limited to 2 GB in size for the data fork and 16 MB for the resource fork, constrained by the signed 32-bit integer fields in the catalog file record that store fork lengths. This upper bound is theoretically reachable via the file's eight primary extents (each up to 65,535 allocation blocks) plus overflow extents tracked in a dedicated B-tree, though practical fragmentation often prevents it.^[3] To accommodate larger volumes within the fixed block count, HFS dynamically scales the allocation block size based on total capacity—for instance, 8 KB blocks on a 400 MB volume or 32 KB on a 2 GB volume. These volume size limits were later extended in subsequent Mac OS versions, reaching 4 GB with System 7.5 and up to 2 TB with System 7.5.2 and updated drivers on Power Macintosh systems.^[3] While this maintains efficient bitmap management for allocation tracking, it introduces substantial internal fragmentation for small files, as any file smaller than the block size wastes the unused portion of its assigned block. A single 1-byte file on a 2 GB volume, for example, consumes a full 32 KB, amplifying storage inefficiency on drives hosting many modest-sized items like documents or icons.^[3] Performance constraints arise primarily from this block sizing and the lack of native fragmentation mitigation. As files grow or the volume fills, non-contiguous allocation leads to multiple extents per file, increasing overhead in locating and accessing data via the extents B-tree. HFS provides no built-in defragmentation, relying on third-party utilities like Norton's SpeedDisk—introduced in the late 1980s and refined through the 1990s—to reorganize files and reduce seek times on mechanical hard drives. Additionally, the catalog B-tree's depth grows logarithmically with file count, potentially slowing directory traversals on fuller volumes, though the 65,536-file limit keeps depths manageable at typically 3–5 levels.

Reliability Issues

The Hierarchical File System (HFS) exhibited notable vulnerabilities in data integrity, primarily due to its centralized metadata management and lack of advanced recovery features. The catalog file, which stored all records for files and directories, represented a single point of failure; corruption in this file could render the entire volume's metadata inaccessible, potentially destroying the file system structure without any built-in redundancy or journaling to facilitate recovery.^[26] Sudden power loss during write operations posed another critical risk, as HFS lacked transaction logging or atomic updates, often resulting in fragmented file extents and inconsistent volume states that prevented automatic repair. Apple mitigated this to some extent by recommending the use of the FlushVol function to periodically commit buffered changes to disk, ensuring that recent modifications were not lost in the event of interruption.^[19] However, without consistent application of such safeguards, extent allocation—used to map file data blocks—could become irreparably scattered, exacerbating data loss. To address routine disk errors, Apple released Disk First Aid in 1988 as a basic utility for verifying and repairing HFS volumes, capable of fixing minor issues like lost allocation blocks but often failing against extensive corruption requiring manual intervention or data recovery.^[27] Early HFS implementations prior to System Software 4.1 (released in 1987) contained bugs in B-tree handling that could lead to index overflows, causing files to become inaccessible or lost during volume operations; these were resolved in subsequent updates to improve structural stability.^[19] Additionally, versions up to 6.0.7 had flaws in range-locking functions like PBLockRange, which mishandled byte offsets and risked data corruption during concurrent access.^[19] Given these limitations, Apple advised users to perform frequent manual backups by copying files to secondary volumes, as HFS provided no native snapshot or versioning capabilities to capture point-in-time states. Third-party software, such as Retrospect from Dantz Development (later acquired by EMC), emerged to offer more robust HFS-specific backup and restore functionality, including support for hierarchical structures and resource forks.^[28]

Legacy and Successors

HFS Plus

HFS Plus, also known as Mac OS Extended, was released on January 19, 1998, with Mac OS 8.1 as an evolutionary upgrade to the original Hierarchical File System, designed to overcome constraints in storage capacity and global usability without a complete redesign.^[4]^[29] It employs 32-bit values for allocation blocks, enabling a default block size of 4 KB and vastly expanding limits to support volumes up to 8 exabytes (2⁶³ bytes) and individual files up to 8 exabytes per fork, while using 32-bit file IDs for improved scalability.^[4] Among its key enhancements, HFS Plus supports file names up to 255 characters encoded in UTF-16 for better internationalization, introduces an optional journaling capability added via a Mac OS X 10.2.2 update in November 2002 to log changes and enhance crash recovery, and implements hot-file clustering to group frequently accessed small files contiguously for faster retrieval.^[4]^[30] The format ensures backward compatibility with original HFS systems through a wrapper that embeds the HFS Plus structures within an HFS-compatible master directory block, allowing older Mac OS versions to recognize and mount the volumes as HFS. In modern macOS versions, the original HFS volumes are supported in read-only mode natively, with full write access available via third-party software.^[4]^[31] HFS Plus quickly became the default file system for Mac OS 9 and the initial releases of Mac OS X, serving as the required format for volumes exceeding 2 GB since the original HFS was capped at that size.^[4]^[32] Compared to HFS, HFS Plus accommodates up to eight extents per file fork directly in the catalog file, with additional extents managed in a dedicated overflow B-tree file to handle larger or more fragmented files more efficiently. It incorporates Unix-style permissions through extended file attributes for better integration with POSIX-compliant systems, while preserving the unchanged data and resource fork model but with enhanced indexing and access support. The underlying B-tree structures are extended to manage longer keys and Unicode but retain core similarities to HFS.^[4]

Transition to Modern File Systems

The transition from the Hierarchical File System (HFS) family to modern file systems began with the introduction of the Apple File System (APFS) in macOS High Sierra (version 10.13) in 2017, which became the default format for solid-state drives (SSDs) while HFS+ remained the standard for mechanical hard disk drives (HDDs).^[33] This shift marked the start of HFS+'s deprecation as Apple's primary file system, with APFS offering improved performance optimized for flash storage.^[34] HFS+ continued to receive full read/write support for external volumes and data storage in subsequent macOS releases, but its use was increasingly discouraged in favor of APFS for new installations.^[1] In macOS Catalina (version 10.15) released in 2019, Apple mandated APFS for the system volume on all installations, effectively ending HFS+ as a bootable format for the primary operating system drive, though external HFS+ volumes retained full read and write compatibility. Full read/write support for HFS+ volumes persists in current macOS versions (as of macOS Sequoia in 2024), allowing access to older data without conversion, but Apple no longer recommends HFS+ for new formatting or backups.^[35]^[1] With the introduction of Apple Silicon Macs in 2020, boot volumes must use APFS, further limiting HFS+ to non-bootable, external data roles.^[36] Migration from HFS+ to APFS was facilitated by built-in tools in macOS High Sierra, which automatically convert qualifying SSD volumes during installation without data loss, though HDDs and existing Time Machine backups on HFS+ require manual handling or reformatting to initiate APFS use.^[37] As of macOS Sequoia (2024), Time Machine requires APFS for new backup disks, automatically formatting them as such if possible, and will not start new backups on HFS+ volumes, though pre-existing HFS+ backups remain supported.^[38]^[39] For cross-platform needs, third-party drivers like Paragon HFS+ for Windows continue to provide read/write access to HFS+ volumes as of 2025, bridging the gap for users interacting with legacy Mac-formatted drives on non-Mac systems.^[40] The primary motivations for replacing HFS and HFS+ with APFS include enhanced native encryption for individual files, support for snapshots to enable efficient backups and versioning, and fast cloning for duplicate volumes without full data copying—features absent or limited in the HFS family.^[41] These advancements address longstanding limitations in security, space efficiency, and performance on modern hardware, particularly SSDs, while HFS+ compatibility was briefly retained in transitional Apple Silicon setups for recovery and external booting before full APFS enforcement.^[34]

References

[1]
File system formats available in Disk Utility on Mac - Apple Support
In Disk Utility on your Mac, format disks or volumes using Apple File System (APFS), Mac OS Extended, MS-DOS (FAT), and ExFAT.
[2]
[PDF] Introduction to Files
In HFS, files are grouped into directories (also called folders), which themselves are grouped into other directories, as illustrated in. Figure 1-4. The number ...
[3]
Hierarchical File System (HFS) Format Specifications (Apple KB ...
Jan 1, 2018 · This article explains the various limits for partition sizes, and number of files under different versions of the OS
[4]
Technical Note TN1150: HFS Plus Volume Format - Apple Developer
An HFS Plus volume contains five special files, which store the file system structures required to access the file system payload: folders, user files, and ...
[5]
File System Basics - Apple Developer
Apr 9, 2018 · APFS is the default file system in macOS, iOS, watchOS, and tvOS. APFS replaces HFS+ as the default file system for iOS 10.3 and later, and ...
[6]
A brief history of Mac native file systems - The Eclectic Light Company
Apr 12, 2025 · A brief start with MFS for 400 KB floppies, followed by HFS intended for the first hard disks, upgraded to HFS+ in 1988, and followed in ...
[7]
https://patents.google.com/patent/US4945475A/en
[8]
Macintosh Hard Disk 20 - Mac GUI
After announcing its external 20MB hard disk in April 1985, Apple introduced the HD20 on September 17, 1985, with a suggested retail price of $1499 and a ...
[9]
Mac System Software 2.1 - BetaWiki
May 26, 2025 · Mac System Software 2.1 is the second release in the Mac System Software 2.x series, released in September 1985. It introduced support for Apple's Hard Disk 20.<|control11|><|separator|>
[10]
A Brief History of the Classic Mac OS
Jul 26, 2012 · HFS+ volumes supported larger volumes while at the same time allocating drive space more efficiently, using smaller chunks than the previous HFS ...<|control11|><|separator|>
[11]
The Mac Plus 30 Years On - Low End Mac
Jan 24, 2016 · The Mac Plus, introduced on January 16, 1986, changed all that. ... Mac's new Hierarchical File System (HFS). The new ROMs are 128 KB ...
[12]
Floppy Disk Compatibility and Incompatibility in the Mac World
Aug 16, 2016 · (HFS had been introduced in 1985 to support Apple's first Mac hard drive, the 20 MB Hard Disk 20, which connected via the slow floppy disk port.
[13]
Apple Macintosh Plus (1986) - MESS Redump
The extended ROM held the new version of operating system: it supported hard disk units, the SCSI bus, and the new file system: HFS (Hierarchical File ...
[14]
1986: Mac Plus, 512Ke, HFS Disks, and the LaserWriter Plus
In April 1986, Apple discontinued the Macintosh 512K, replacing it with the 512Ke. This used the same 128KB ROMs and the same 800KB floppy drive as the Plus.
[15]
https://apple2history.org/appendix/ahb/ahb4/
[16]
Looking for High Sierra - The OS/2 Museum
Oct 29, 2021 · The High Sierra Proposal is long obsolete, and it never even was an official standard, it was the de facto standard from mid-1986 until ISO 9660 was approved.
[17]
A Slow-Motion Revolution | The Digital Antiquarian
Sep 30, 2016 · The so-called “High Sierra” format would be officially published in finalized form in May of 1986. In the run-up to the first Microsoft CD-ROM ...
[18]
Mac OS Operating System
1987 - System 4.0, bug fixes 1987 - System 4.1, improved Finder (supports HDD >32 mbyte) 1988 - System 6, 32-bit color, Quickdraw support, serial port ...
[19]
[PDF] File Manager - Apple Developer
This chapter describes how your application can use the File Manager to store and access data in files or to manipulate files, directories, and volumes.
[20]
Catalog Files (IM: F) - Inside Macintosh
File thread records. A file thread record provides a link between a file and its parent directory. It allows the File Manager to find the name and directory ID ...Missing: note | Show results with:note<|control11|><|separator|>
[21]
[PDF] INSIDE MACINTOSH - Vintage Apple
... File Package Reference.” This section provides a complete reference to the Standard File Package by describing the data structures and routines that it uses.
[22]
[PDF] Introduction to Files
This chapter is a general introduction to file management on Macintosh computers. It explains the basic structure of Macintosh files and the hierarchical ...
[23]
[PDF] More Macintosh Toolbox - Apple Developer
... features you can build into your Macintosh application and documents the system software routines for implementing those features. For information about ...<|control11|><|separator|>
[24]
Managing Classic Mac OS resources in ResEdit
Jul 20, 2024 · ResEdit was a tool to manage resource forks, which stored data like dialogs, menus, and code. It allowed changing dialogs and keyboard layouts.Missing: HFS 'PICT'
[25]
[PDF] Finder Interface Reference
Oct 31, 2006 · For a file, this bit indicates that the file is an alias file. ... Define flags used by the extended file and folder information structures.
[26]
HFS+ Fragmentation | david.roess.li
May 22, 2004 · Remember the days when we use to defrag our disks with Norton SpeedDisk? When was the last time you defragged under Mac OS X? No need to ...
[27]
From BFS to ZFS: past, present, and future of file systems
Mar 16, 2008 · HFS had some other technical limitations that could occasionally leak out. All the records for files and directories were stored in a single ...
[28]
[PDF] Macintosh® Utilities User's Guide - Vintage Apple
Chapter 3 describes Disk First Aid TM, which is also found on Utilities disk 1. You use Disk First Aid to examine and repair damaged disks. Please note: Disk ...<|separator|>
[29]
[PDF] Retrospect Backup 19 - Mac User's Guide - Amazon S3
Jun 2, 2025 · Retrospect now pre-scans NTFS and HFS+ volumes connected to the backup server and Retrospect clients, speeding overall backup and restore ...
[30]
1998: Good-bye Newton; Hello OS 8.1, WallStreet, and iMac
Dec 31, 1998 · Mac OS 8.1 was a free maintenance upgrade to Mac OS 8 that was released in January 1998. The big improvementm was HFS+, a new filing system that ...
[31]
HFS Plus - Apple Wiki | Fandom
It was introduced with Mac OS 8.1 in 1998 and remained in use until it was deprecated with the release of the Apple File System (APFS) with macOS 10.13 ( ...
[32]
HFS+ Overview - NTFS.com
Mac OS Extended format (HFS+) is a hard disk format introduced on January 19, 1998, by Apple Inc. to replace their HFS and the primary file system in Macintosh ...
[33]
macOS High Sierra advances storage, video and graphics - Apple
Jun 5, 2017 · Apple File System (APFS) features enhanced performance, security and reliability of data and provides a foundation for future storage ...
[34]
Apple File System Guide
Jun 4, 2018 · It is optimized for Flash/SSD storage and features strong encryption, copy ... APFS replaces HFS+ as the default file system for iOS 10.3 ...
[35]
Should you continue using HFS+? - The Eclectic Light Company
May 16, 2022 · Which is faster with a hard disk: using APFS or sticking with HFS+? Are there any differences in their performance on SSDs?Missing: 1980s | Show results with:1980s
[36]
How to use an external storage device as a Mac startup disk
If you're using a Mac with Apple silicon, plug your storage device into any compatible port except the DFU port. Learn how to identify the DFU port. After macOS ...
[37]
Frequently Asked Questions - Apple Developer
Jun 4, 2018 · Apple File System Guide. PDF Companion File. Table of Contents. Jump To ... HFS stores filenames on disk in UTF-16 encoding. APFS doesn't ...
[38]
Types of disks you can use with Time Machine on Mac - Apple Support
APFS or APFS Encrypted disks are the preferred format for a Time Machine backup disk. If you select a new backup disk that's not already formatted as an APFS ...<|separator|>
[39]
HFS+ for Windows by paragon software
What versions of the HFS file system are supported? HFS+ for Windows by Paragon Software supports HFS+ (Mac OS Extended), JHFS+ (Journaled Mac OS Extended), ...
[40]
Volume Format Comparison - Apple Developer
Jun 4, 2018 · Features · Encryption · Crash Protection · Fast Directory Sizing · Atomic ... Snapshots. ✓. Space sharing. ✓. Native encryption. ✓. Sparse files.