Skip to content

FSEvents Flags Explained: Every Bit, Decoded

Every on-disk FSEvents flag bit with its value, the names FSEventsParser and mac_apt use, and how to read Created, Renamed, ItemCloned or EndOfTransaction.

Published on 4 min read

TL;DR. The flags field is a 32-bit little-endian bit set. Read that way, Created is 0x00000001, Removed 0x00000002, Renamed 0x00000008, Modified 0x00000010, and the item type sits in the high bits (File 0x00800000, Folder 0x01000000). FSEventsParser reads the same four bytes big-endian, so its constants are byte-swapped (Created = 0x01000000), with the same names. None of these equal Apple's kFSEventStreamEventFlag* API values.

The table

Values are the u32 read little-endian (mac_apt's convention). The FSEventsParser column shows the same bit in its big-endian convention.

Bit (LE)FSEventsParser (BE)Name (FSEventsParser / mac_apt)Meaning
0x000000010x01000000CreatedItem created
0x000000020x02000000RemovedItem removed
0x000000040x04000000InodeMetaModInode metadata changed (e.g. mode, timestamps)
0x000000080x08000000Renamed / RenamedOrMovedRenamed or moved
0x000000100x10000000ModifiedContent modified
0x000000200x20000000ExchangeSwapped with another item (atomic save)
0x000000400x40000000FinderInfoModFinder info changed
0x000000800x80000000FolderCreatedFolder created
0x000001000x00010000PermissionChangePermissions or ownership changed
0x000002000x00020000ExtendedAttrModified / XAttrModifiedExtended attribute set or changed
0x000004000x00040000ExtendedAttrRemoved / XAttrRemovedExtended attribute removed
0x000010000x00100000DocumentRevisioning / DocumentRevisionDocument versions store involved
0x000040000x00400000ItemClonedAPFS clone (copy-on-write copy), High Sierra and later
0x000800000x00000800LastHardLinkRemovedLast hard link to an inode removed
0x001000000x00001000HardLinkItem is a hard link
0x004000000x00004000SymbolicLinkItem is a symbolic link
0x008000000x00008000FileEvent / FileItem is a file
0x010000000x00000001FolderEvent / FolderItem is a folder
0x020000000x00000002MountA volume was mounted at this path
0x040000000x00000004UnmountA volume was unmounted from this path
0x200000000x00000020EndOfTransactionMarks the end of a group of related changes

Other bits have no documented meaning. The FSEvents Parser shows them in hex rather than guessing, and FSEventsParser labels them NOT_USED; seeing them in carved data is a hint that the record is damaged.

Reading combinations

A record carries every change fseventsd merged for that path (see coalescing):

  • Created;Modified;FileEvent: a file was written. The usual shape of a new document or download.
  • Created;Modified;Removed;FileEvent: a short-lived file (temporary files, installer scratch data, a file created then deleted within the same flush). The order inside the record is not recorded.
  • Renamed;FileEvent twice, same node ID: a rename or move; the lower event ID is usually the old path. On 1SLD there is no node ID and pairing relies on consecutive IDs.
  • ExtendedAttrModified on a new download: typically the quarantine and where-from attributes being set.
  • ExtendedAttrRemoved on extracted or downloaded items: an attribute was removed. Stripping com.apple.quarantine is one reason, see quarantine attribute; many apps remove attributes routinely.
  • InodeMetaMod alone: a chmod, touch or ownership change; making a downloaded helper executable often looks like this.
  • Mount;FolderEvent on Volumes/NAME: a volume attached at that mount point. The volume's own .fseventsd then logs what was written to it.
  • ItemCloned: an APFS clone, e.g. a Finder duplicate or cp -c. The clone and its source share data blocks.

API constants are different

Apple's documented FSEventStreamEventFlags (kFSEventStreamEventFlagItemCreated = 0x100, …ItemIsFile = 0x10000, and so on) describe what a running app receives from the FSEvents API. They do not match the bits written to .fseventsd, as noted by Nicole Ibrahim's research and mac_apt's source. A parser that applies the API table to log files produces wrong names.

How the parser shows flags

The FSEvents Parser shows change flags as labelled chips, the item type in its own column, the raw value (e.g. 0x00800011) and the FSEventsParser-style names in the record detail and in CSV exports. The change filter groups bits into Created, Removed, Renamed, Modified/cloned, metadata/attributes and mount/unmount.

FAQ

Are FSEvents log flags the same as the FSEventStream API flags?

No. The bits stored in .fseventsd logs differ from Apple's public kFSEventStreamEventFlag constants. Use a table built for the on-disk format.

What does ExtendedAttrRemoved mean?

An extended attribute was removed from the item. FSEvents does not say which one; removing com.apple.quarantine is one possibility among many.

Related articles