macOS FSEvents Forensics: What .fseventsd Proves

TL;DR. FSEvents is a path-level history of each macOS volume: which files and folders were created, modified, renamed or removed, in which order. It has no timestamps, no user and no process, but it often remembers files that are long gone. Collect the whole .fseventsd folder with its file modification times and read it with a parser that keeps the time uncertainty visible, such as the FSEvents Parser on this site.

What fseventsd writes

The fseventsd daemon exists so that Time Machine, Spotlight and sync clients can ask "what changed under this folder since point X?" without rescanning the disk. To answer across reboots it keeps a persistent journal on every writable volume it tracks, in a hidden folder at the volume root:

The folder holds gzip-compressed log files with 16 hex-digit names, a fseventsd-uuid file identifying the event stream and, sometimes, a no_log marker. Inside each log are one or more pages of records. A record is:

• a path, relative to the volume root (Users/dana/Downloads/tools.zip);
• a 64-bit event ID from a system-wide counter that only goes up;
• a 32-bit set of flags: what happened (created, removed, renamed, modified, extended attribute changed…) and to what (file, folder, symlink, hard link);
• from macOS 10.13, a node ID; from macOS 14, four more bytes whose meaning Apple has not documented.

The byte-level layout is in the FSEvents file format article.

What it proves

• Existence. A path appears in a record, so an item with that name existed at that location on that volume, even if it was deleted since.
• Kind of change. Created, modified, renamed or moved, removed, permissions changed, extended attribute added or removed, Finder info changed, cloned.
• Order. Event IDs increase monotonically, so records can be put in sequence with confidence, across volumes of the same Mac too.
• Removable media use. The Data volume logs Volumes/<name> mount and unmount events; the drive's own .fseventsd logs what was written to it.

What it does not prove

• When, exactly. There is no timestamp in a record. See dating FSEvents records.
• Who or what. No user or process is recorded. The 3SLD extra field is decoded as a user ID by FSEventsParser; treat that as unconfirmed.
• Every step. Changes to one path close together are coalesced into one record: Created;Modified;Removed in a single row does not tell you the order.
• Content. Only names. Pair with APFS snapshots, Time Machine or carving to recover data.
• Network shares and read-only volumes. Not logged.

Where it pays off

1. Persistence. A LaunchAgent plist created in ~/Library/LaunchAgents, even if removed later.
2. Staging and cleanup. Dozens of documents appearing in a hidden folder, then removed in one burst.
3. Downloads. An archive that sat in Downloads for ten minutes, with a quarantine attribute added, then an attribute removed from its extracted content.
4. Privacy permissions. Writes to the TCC database around the time Terminal got Full Disk Access.
5. USB exfiltration. A Volumes/EXFIL mount on the Mac, and on the stick itself, the list of files written.

The worked exfiltration example shows all five in one fictional case.

Reading it well

• Filter by path first. A busy Mac produces hundreds of thousands of records a day. Start from Users/*/Downloads, Library/LaunchAgents, Users/Shared, private/tmp and Volumes/, then widen.
• Follow node IDs through renames. A rename is two records (old and new path) that share a node ID on 2SLD and 3SLD.
• Keep the uncertainty. Report "between 10:09:55 and 10:23:18 UTC", not "at 10:23:18".
• Correlate. Quarantine events, Unified Logs, APFS timestamps and the flags reference narrow the story.
• Collect correctly. Modification times are your only clock: see how to collect .fseventsd.

FAQ

What is FSEvents in macOS forensics?

A persistent log of file system changes written by the fseventsd daemon into a hidden .fseventsd folder on each volume. Each record holds a path, an event ID and flags such as Created, Removed or Renamed.

Does FSEvents record deleted files?

Yes. A removal is logged as a record with the Removed flag and the full path, so FSEvents often keeps the name and location of files that no longer exist.

Does FSEvents have timestamps?

No. Records only carry an event ID. Time is estimated from the modification times of the log files, which gives a window rather than a moment.