Skip to content
FSEvents Parser

Dating FSEvents Records Without Timestamps

FSEvents records have no time. How to build honest time windows from .fseventsd log file modification times, uuid files and dated paths, and when they fail.

Published on 4 min read
fseventstimelinemacos-forensicsdfir

TL;DR. A record was written to its log file between that file's predecessor's modification time and its own modification time. That window, plus the order given by event IDs, is what FSEvents can tell you about time. Everything else (a dated path, an APFS timestamp, a Unified Log entry) is correlation. Report ranges and name your anchor.

Why there is no timestamp

Each record holds a path, an event ID, flags and (on newer versions) a node ID. The event ID is a counter, not a clock. The only times available are file-system metadata of the log files themselves and of fseventsd-uuid.

The window method

fseventsd buffers events in memory and appends them to the current log file, starting a new file from time to time. So for the log files of one volume, sorted by event ID:

  • a file's modification time is when its last records were flushed: an upper bound for every record in it;
  • the previous file's modification time is roughly when this file started: a lower bound;
  • for the oldest file, fseventsd-uuid's modification time (when this history began) is the only lower bound, and it can be months earlier.

Example from the sample shipped with the FSEvents Parser:

Log filemtime (UTC)Window of its records
…12a4439d09:58:4009:31:07 → 09:58:40
…12a444cf10:09:5509:58:40 → 10:09:55
…12a4475910:23:1810:09:55 → 10:23:18

A LaunchAgent created in the third file was written between 10:09:55 and 10:23:18 UTC. That is the statement to make, not "10:23:18".

Tightening the window

  • Event order. Within a window, records are ordered. If the LaunchAgent's record comes after a Terminal preference change and before a TCC.db write, and either of those can be dated elsewhere, the window shrinks.
  • Dated paths. Rotated logs, diagnostic reports and snapshots often carry a date in their name (…-2026-09-14-091214.ips). When such a path is Created, it anchors nearby event IDs. FSEventsParser uses a set of known paths for its approximate-date column; the FSEvents Parser lists the dates it sees in created paths for each log file as hints.
  • Other artifacts. APFS birth and modification times of the item if it still exists, quarantine events for downloads, Unified Logs for launchd loads, TCC.db rows with their own timestamps.

When the method breaks

  • Copied without times. A Finder drag to some destinations, AirDrop, e-mail or a careless upload stamps every file with the copy time. Symptom: all log files share nearly the same mtime. The parser flags this and the windows must be ignored; order is still valid.
  • Out-of-order mtimes. A file whose mtime is earlier than its predecessor's (clock changes, touched files, tools that rewrite files). That file gets no lower bound.
  • ZIP local times. ZIP stores times without a time zone unless it carries the extended timestamp field; a collection zipped in one zone and read in another shifts every window by the offset. Prefer tar.gz.
  • Long quiet periods. On a machine that sleeps for days, a window can span days; the upper bound is still sound.
  • The current log. The newest file may still be open when collected; its mtime is the collection time or the last flush.

Filtering by time

Two questions need two different filters, which the parser's time range offers as a time field:

  • Approximate window (overlaps): keep a record if its window overlaps the range. Nothing possibly inside the range is missed; some records outside it may be included.
  • Log file written (upper bound): keep a record if its file's mtime is in the range. Tighter, but a record written just before a flush that falls outside the range is missed.

Use the first to be exhaustive, the second to focus. Either way the range is applied to every view, count, finding and export, and it is kept in the URL (#from=…&to=…), so a shared link reopens the same window.

FAQ

How accurate is an FSEvents time window?

As accurate as the gap between two log file flushes, typically minutes to hours on an active Mac, and much wider on an idle one. It is a range, never a moment.

What if all FSEvents log files have the same modification time?

They were almost certainly copied without preserving times. Record order is still valid, but the windows are meaningless; recollect with tar, ditto or UAC, as described in the collection guide.

Related articles