fseventsd

fseventsd is the macOS daemon behind the FSEvents API. Time Machine, Spotlight, backup tools and sync clients use it to learn which folders changed since a given point without rescanning the disk. To answer that question across reboots, it keeps a persistent journal in a hidden .fseventsd folder at the root of each writable volume it tracks.

The folder holds gzip-compressed log files with 16 hex-digit names (each name is an event ID), made of DLS pages of records; a fseventsd-uuid file identifying the event stream; and, sometimes, a no_log marker. Each record holds a path relative to the volume root, an event ID, flags and, from macOS 10.13, a node ID.

Why it matters in investigations

The journal is a path-level history of the volume. It often remembers files that no longer exist: a removal is logged with the full path, so deleted downloads, staging folders and persistence files can still be named. It also records mounts of external drives and, on those drives, what was written to them.

Its limits are just as important. Records have no timestamp, no user and no process. Changes to one path close together are coalesced. Read-only volumes and network shares are not logged. How far back the history reaches varies from Mac to Mac.

Because fseventsd keeps writing, attaching an evidence drive read-write to an analysis Mac will add new logs to it: use a write blocker or a read-only mount.

Example

On macOS 10.15 and later the folder that matters is /System/Volumes/Data/.fseventsd, on the Data volume; on 10.14 and earlier it is /.fseventsd; each external drive has its own /Volumes/<name>/.fseventsd.

Related terms

• DLS page
• Event ID
• fseventsd-uuid
• no_log

Read a .fseventsd folder in the FSEvents Parser; the FSEvents forensics guide explains what it can and cannot prove.