Apple Filesystems (APFS and HFS+)

What is it?

APFS is the filesystem of every Mac since macOS 10.13, and HFS+ (Mac OS Extended) is its predecessor, still common on older external drives and Time Machine disks. Impossible OS recognises both partition types by name but cannot read either. This roadmap adds read-only drivers for both in twelve sections, none of them started. Writing is out of scope on purpose: APFS's object-map updates are only partly reverse-engineered, and the use case is copying files off a Mac-formatted drive.

How does it work?

Today: partition names only. gpt.c defines the GPT partition type GUIDs GPT_GUID_APPLE_HFS (48465300-0000-11AA-AA11-00306543ECAC) and GPT_GUID_APPLE_APFS (7C3457EF-0000-11AA-AA11-00306543ECAC), declared in gpt.h, and gpt_type_name() turns them into "Apple HFS+" and "Apple APFS". On MBR disks, type 0xAF is named "HFS+" (mbr.h, mbr.c). The partition scan in partition.c logs each partition with that name at debug level, but its filesystem probe has no Apple check, so the partition is classed unknown and gets no drive letter.

Planned design, APFS. An APFS partition is a container holding one or more volumes, and almost every lookup goes through an object map:

Read the container superblock, verify its Fletcher-64 checksum, and find the latest valid checkpoint.
Walk the container's object map, a B-tree from object ID and transaction ID to physical block, taking the newest version not later than the checkpoint.
Mount each volume, detecting sealed system volumes.
Search and walk the filesystem B-tree for inodes, directory records, file extents, symbolic links and extended attributes.
Return STATUS_ACCESS_DENIED for files on a FileVault-encrypted volume rather than returning ciphertext.
Convert names from the decomposed Unicode form macOS stores to the composed form Windows displays.

Planned design, HFS+. Read the volume header (H+ or the case-sensitive HX variant), replay the journal if the volume was not cleanly unmounted, then read directories from the catalog B-tree and file data from inline extents plus the extents overflow B-tree.

Both drivers will only probe partitions whose GPT type GUID is Apple's, so a non-Apple partition is never misread.

flowchart TD
    G[GPT type GUID] -->|APFS| C[container superblock + Fletcher-64]
    C --> O[object map B-tree]
    O --> V[volume superblock]
    V --> F[filesystem B-tree: inodes, dirs, extents]
    G -->|HFS+| H[volume header + journal replay]
    H --> K[catalog B-tree]
    K --> E[extents overflow B-tree]
    F --> M[read-only VFS mount]
    E --> M

What are its interfaces?

Interface	Purpose
`GPT_GUID_APPLE_APFS`, `GPT_GUID_APPLE_HFS`, `gpt_guid_equal()`, `gpt_type_name()`	Recognise Apple partitions (`gpt.h`)
`MBR_TYPE_HFS_PLUS` (`0xAF`)	HFS+ on MBR disks (`mbr.h`)

No filesystem interface exists yet; the drivers will add apfs_probe() and hfsplus_probe() and register read-only vfs_ops tables.

How do I use it?

It cannot be used yet. With debug logging on, an attached Mac disk shows up in the partition scan as Disk <d>, Partition <p>: Unknown, <n> MiB (Apple APFS) (or Apple HFS+), and nothing mounts.

What is not implemented yet?

Everything in the roadmap:

APFS: Container Superblock + Fletcher-64, Object Map B-Tree, Volume Mount, Filesystem B-Tree Search + Walk, Inode Reader, File Extent Reader, Directory Reader and Symlinks + XAttrs.
HFS+: Volume Header + Journal Replay, Catalog B-Tree + Directory Reader and File Read + Extents Overflow B-Tree.
Mounting both (VFS Registration).

How does it compare with Windows 11 and Linux?

Windows 11 reads neither APFS nor HFS+ without third-party software such as Paragon's drivers. Linux has an in-kernel hfsplus driver (read-only for journaled volumes by default) but no upstream APFS driver; apfs-fuse reads APFS in user space. Impossible OS plans native in-kernel read-only drivers for both.