APFS Timestamps and Local Snapshots on macOS

What it is

APFS is the default file system on macOS since 10.13 High Sierra for SSD boot volumes. Every inode stores four timestamps with nanosecond resolution, and every directory entry stores a separate Date Added value. APFS is copy-on-write, so it can also keep cheap read-only snapshots of a volume. Time Machine uses them as "local snapshots", and macOS takes one before installing updates.

Together these give you the first layer of any Mac timeline, a way to test timestamps for tampering, and sometimes a copy of a file that has since been changed or deleted. The APFS snapshots and timestamps guide explains the volume layout and copy behaviour in depth; this page is the quick reference.

Where it lives

Protection: stat works for anything the user can see. Listing and mounting snapshots needs root, and reading TCC-protected paths inside a mounted snapshot still needs Full Disk Access. Offline, a FileVault or Apple silicon Data volume must be unlocked first.

What it proves

• When a file inode was created (birth), when its content last changed (mtime), when its metadata last changed (ctime).
• When an item was placed in its current folder (Date Added), independent of the file's own timestamps.
• That a file existed, with specific content, at the time of a snapshot.
• Likely timestomping, when ctime, nanoseconds or Date Added contradict mtime and birth time.

It does not prove:

• That a file was read. Access time is updated lazily by default (see below).
• Who made a change. Timestamps have no user or process attached.

Key fields

Access time policy: unless the volume has the APFS_FEATURE_STRICTATIME flag, APFS only updates access_time on a read when the stored value is older than mod_time. The Data volume normally mounts without strict atime, so atime is weak evidence of reading.

Timestamps

All APFS timestamps, including date_added, are 64-bit counts of nanoseconds since 1970-01-01 00:00:00 UTC. Finder shows only whole seconds; stat can show more.

# Readable birth, modify, change, access
stat -f "B:%SB M:%Sm C:%Sc A:%Sa" -t "%Y-%m-%d %H:%M:%S %z" report.pdf

# Raw nanosecond value to a date (divide by 1e9)
date -u -r $(( 1759133456123456789 / 1000000000 ))

Local snapshot names embed a date and time: treat it as the approximate creation time, and confirm the time zone on the evidence system before relying on it.

Retention

• File timestamps persist until the next change of that kind; ctime changes on nearly any metadata edit.
• Time Machine local snapshots: Apple documents one snapshot of the startup disk roughly every hour, each kept for 24 hours, plus one for the last successful backup, kept until space is needed. Low free space can purge them sooner.
• Snapshots only exist when Time Machine (or other snapshot-using software) is active, so many Macs have none.

Collection

Record snapshot state first, since it changes on its own:

tmutil listlocalsnapshots /
tmutil listlocalsnapshotdates /
diskutil apfs listSnapshots /System/Volumes/Data

Mount a snapshot read-only and copy out what you need (root, Full Disk Access):

sudo mkdir /tmp/snap
sudo mount_apfs -o rdonly -s com.apple.TimeMachine.2026-09-28-101500.local /System/Volumes/Data /tmp/snap
sudo ditto /tmp/snap/Users/alice/Downloads /Volumes/CASE/MBP01/snap_Downloads
sudo umount /tmp/snap

• UAC ir_triage runs tmutil listlocalsnapshots and tmutil listlocalsnapshotdates and builds a bodyfile of file timestamps.
• Aftermath with --deep walks the file system for birth, modified and accessed times; its default run covers common directories.
• tmutil localsnapshot creates a new snapshot to freeze the volume before a long logical collection. It changes the system, so document it.
• Dead-box: image the whole container; tools that understand APFS volume groups then expose both volumes and snapshots.

Parsing

• libfsapfs: fsapfsinfo inspects a container and can write a bodyfile of all file entries; fsapfsmount mounts a volume from an image. Encrypted volumes take a password or recovery key option.

# -o takes the byte offset of the APFS container inside the image
fsapfsinfo -o <container_offset_bytes> -B /cases/MBP01/apfs.body /cases/MBP01.raw

• The Sleuth Kit includes APFS support (pool layer) for image-level listing.
• mac_apt opens APFS images (including separately mounted System and Data volumes) and, given a password or recovery key, encrypted ones; its plugins then report timestamps per artifact.
• Convert bodyfiles to a timeline with your usual tooling (for example mactime from The Sleuth Kit).

Investigator tips

• A birth time earlier than Date Added is normal for downloads and copies: the file existed elsewhere first.
• touch and similar tools cannot set ctime. An old mtime with a recent ctime needs an explanation.
• Timestamps set from a typed value often have a zero nanosecond part. A cluster of .000000000 values among normal neighbours is a strong hint of timestomping.
• Cross-check with FSEvents (InodeMetaMod), Spotlight Date Added and quarantine events, none of which touch rewrites.
• Deduplicate firmlink duplicates (/Users/... versus /System/Volumes/Data/Users/...) by inode, not path.
• Live copying reads files and may touch atime. Prefer imaging, or collect from a mounted snapshot.
• For longer history than local snapshots, look at Time Machine backups on external or network destinations.