Glossary
DLS page (1SLD, 2SLD, 3SLD)
The block structure inside decompressed FSEvents logs: a 12-byte header with a 1SLD, 2SLD or 3SLD magic, then packed records.
A DLS page is the block structure inside a decompressed FSEvents log file. Each .fseventsd log is a gzip file; once inflated, it is a sequence of pages, and each page starts with a 12-byte header:
| Offset | Size | Field |
|---|---|---|
| 0 | 4 | Magic: the ASCII bytes 1SLD, 2SLD or 3SLD |
| 4 | 4 | Unknown |
| 8 | 4 | Page size, u32 little-endian, header included |
Records are packed back to back after the header until the page size is reached. The magic sets the record layout: a 1SLD record is a NUL-terminated path followed by an event ID and flags (12 bytes); 2SLD adds an 8-byte node ID (20 bytes, macOS 10.13 and later); 3SLD adds four more bytes (24 bytes, macOS 14 and later) whose meaning Apple has not documented. Some write-ups say "DLS1/DLS2" because the magic read as a little-endian integer spells that; the bytes on disk are 1SLD.
Why it matters in investigations
The page version tells you what each record can prove. Without a node ID (1SLD), renames can only be paired by consecutive event IDs. A volume used across macOS upgrades can hold several versions side by side. And because Apple does not document the format, knowing the page boundaries is what lets a parser recover from damage: a page whose size runs past the data, or garbage between pages, can be reported and skipped without losing the records around it.
Example
A page header that begins 33 53 4c 44 is a 3SLD page. If bytes 8 to 11 read 2c 1a 00 00, the page is 0x1a2c = 6,700 bytes long, header included. Each record in it is a path, one NUL byte, then 24 bytes of fixed fields.
Related terms
The FSEvents Parser reports the page version and any damage per log file; the full layout is in FSEvents file format: 1SLD, 2SLD and 3SLD pages.