FSEvents flags

FSEvents flags are the 32-bit field stored in every FSEvents record that says what happened to the path and what kind of item it is. The value is stored little-endian. Read that way, the low bits describe the change (Created 0x1, Removed 0x2, InodeMetaMod 0x4, Renamed 0x8, Modified 0x10, ExtendedAttrModified 0x200, ExtendedAttrRemoved 0x400, ItemCloned 0x4000…), and the high bits give the item type (File 0x00800000, Folder 0x01000000, SymbolicLink, HardLink) and volume events (Mount, Unmount, EndOfTransaction).

Why it matters in investigations

The flags are the only description of an event: FSEvents keeps no user, no process and no content. Reading them correctly is the difference between "a file was downloaded" and "a file had its permissions changed".

Three pitfalls come up often:

• Byte order. FSEventsParser reads the same four bytes big-endian and uses byte-swapped constants (Created = 0x01000000). Both conventions give the same names; mixing them does not.
• API constants are different. Apple's public kFSEventStreamEventFlag* values describe what a running app receives, not what is written to .fseventsd. Applying that table to log files produces wrong names.
• Several changes per record. Because of coalescing, one record can carry Created, Modified and Removed at once, in no recorded order.

Bits with no documented meaning are best shown in hex rather than guessed; in carved data they suggest damage.

Example

Related terms

• Event coalescing
• Quarantine attribute
• Node ID
• DLS page

The FSEvents Parser shows flags as labelled chips plus the raw value; every bit is listed in FSEvents flags explained.