HFS

Let’s start with the basics – what is HFS file system? The Hierarchical File System (HFS) is Apple’s original disk file system, introduced back in the mid-1980s to give the Macintosh a structured and organized way to store files. Before HFS appeared, early storage methods on Apple systems were fairly limited and couldn’t support the increasingly complex applications, graphics, and documents Macintosh computers started producing. HFS solved that by introducing a proper directory tree, longer filenames, and a storage layout that felt modern for its time.

History of HFS

Apple rolled out the Hierarchical File System (HFS) in 1985, mainly to move past the older MFS system that shipped with the first Macintosh computers. MFS was fine for those early machines, but its single-level layout became a problem pretty quickly once apps grew bigger and people needed some kind of structure for their files. HFS stepped in to fix that by letting the system use real folders and subfolders, something that feels obvious now, but back then it was a genuinely important upgrade that made the Mac far easier to work with.

Another reason Apple moved to HFS was the shift to larger disks. The original 400 KB and 800 KB floppy-based systems were being replaced with hard drives measured in megabytes, and MFS simply couldn’t manage that scale. HFS divided storage into allocation blocks and used catalog and extents files to track where file data lived, giving the system more flexibility for larger volumes.

During the late ’80s and well into the ’90s, HFS more or less carried the entire classic Mac OS world on its shoulders. It didn’t matter whether the disk was a tiny floppy or one of the “huge” hard drives of that era, HFS was the format everything relied on. For a long time, it handled that job reasonably well, but once storage started creeping into gigabytes and Macs began needing richer metadata, the cracks showed. At that point, Apple realized the old structure couldn’t stretch much further, which is how HFS+ (Mac OS Extended) came into the picture. It kept the spirit of HFS but expanded it so the system could actually grow.

Even after HFS+ arrived, the original HFS didn’t vanish, and stuck around in older Macs, in backup disks people never bothered to reformat, and in bits of software that just expected it to be there. Today, you mostly run into HFS when dealing with vintage Macs, old project archives, or removable media from that era. It’s essentially a legacy format now, but one that still pops up often enough that people occasionally need to understand it.

Data and Resource Forks

One of the most distinctive things about HFS and something that set classic Mac systems apart for years was its use of two separate forks for every file: a data fork and a resource fork. This design wasn’t common outside the Apple world, but it solved several problems that early Macintosh software faced.

• The data fork is the part most people expect. It holds the “main” content of a file (text in a document, pixels in an image, the audio inside a sound file, and so on). If you opened a file on a non-Mac system, the data fork was usually all you saw.
• The resource fork, however, carried extra information that macOS treated as part of the file’s identity. This fork stored things like icons, menu definitions, string tables, dialog layouts, version info, and other interface elements. Instead of scattering that metadata across multiple files or inside the program code, HFS kept it neatly packaged inside the resource fork. For early Mac developers, this made software easier to design and maintain, because apps could separate interface elements from the data itself.

The downside was compatibility. Most non-Apple systems had no idea that a file might contain a second fork, so when users copied a file from a Mac to Windows or shared it online, the resource fork was often lost. In the classic Mac era, entire applications could break if their resource fork disappeared.

Modern macOS still supports resource forks for legacy reasons, but they’re no longer central to how apps work. HFS+ preserved them, and APFS still recognizes them when needed, but today they mostly appear when dealing with old Mac software, archives, and disk images created before the OS X era.

Structure of the HFS File System

The internal layout of the original HFS looks straightforward, but it has its own very “Mac-style” logic.

• Almost everything revolves around a few central records that describe how the whole volume is organized. The main one is the Volume Header (older manuals call it the Master Directory Block). It acts like a summary page: it lists the size of the volume, the number of allocation blocks, and where the system should look for the core file system structures.
• Once you get past the header, most of the “real” action in HFS happens in the Catalog File. Think of it as a big B-tree database that keeps track of every single file and folder on the disk. It’s the part that actually maintains the hierarchy and helps the system figure out what belongs where. And when a file grows too large for the information stored in its main catalog entry, HFS falls back on another B-tree (the Extents Overflow File), which basically fills in the missing details and tells macOS where the remaining pieces ended up.
• The actual data sits in allocation blocks, which are chunks of space the file system hands out depending on the size of the drive. Bigger disks meant bigger blocks, which is why old HFS volumes often wasted space on tiny files.
• There’s also a small patch of metadata called Finder Info. Classic Mac OS used it for interface-related details (like a file’s icon, where a window last sat on the screen, or what color label it had). Modern systems hide that kind of information inside more unified metadata structures, but HFS treated the Finder as a central part of the system, so it kept this info in its own separate spot.

Benefits and Limitations of the HFS File System

Like any file system, HFS has its strengths and its weaknesses. In the section where we first talked about what is HFS, we briefly touched on some of these points, but it makes sense to go over them properly so everything lines up in a clear comparison. The table below sums up the main pros and cons in a simple, readable way:

Even though HFS and HFS+ served the Mac ecosystem for years, both systems share the same weakness: once a volume becomes damaged, native macOS tools don’t always manage to repair it fully. Old disks, unexpected shutdowns, or a corrupted allocation structure often leave users with partitions that fail to mount at all. If you ever run into that kind of situation, you may need something more capable than the built-in utilities. In that case, our list of the Best Partition Recovery Software can help.

FAQs