Skip to content

FSEvents-Dateiformat: 1SLD-, 2SLD- und 3SLD-Seiten

Das On-Disk-Layout der macOS-.fseventsd-Logs: gzip-Dateien, DLS-Seitenheader, Datensatzfelder je Version und Umgang mit abgeschnittenen oder beschädigten Daten.

Veröffentlicht am 4 Min. Lesezeit

Kurzfassung. Jedes .fseventsd-Log ist eine gzip-Datei. Dekomprimiert ist es eine Folge von Seiten; jede Seite beginnt mit einem 12-Byte-Header (1SLD, 2SLD oder 3SLD, vier unbekannte Bytes, eine Little-Endian-Seitengröße), gefolgt von Datensätzen: einem NUL-terminierten Pfad und 12, 20 oder 24 Bytes fester Felder. Dieses Layout entspricht dem, was FSEventsParser (Nicole Ibrahim, Apache-2.0) und mac_apt (ydkhatri, MIT) implementieren; Apple dokumentiert es nicht.

Der Ordner

.fseventsd/
  0000000012a44181      gzip log file; name = an event ID in hex
  0000000012a4439d
  fseventsd-uuid        text: the stream UUID
  no_log                optional, empty: logging disabled

Die Namen der Logs bestehen aus 16 Hexadezimalziffern. FSEventsParser behandelt einen Namen als letzte Event-ID der Datei; der FSEvents Parser auf dieser Website gleicht den Namen mit den enthaltenen IDs ab und markiert Dateien, deren Name außerhalb ihres eigenen Bereichs liegt (umbenannte oder falsch zugeordnete Dateien).

gzip-Schicht

Jedes Log ist ein gewöhnlicher gzip-Stream (RFC 1952). Manche Dateien enthalten mehr als ein gzip-Member, und Kopien eines Logs, das noch geschrieben wurde, enden vorzeitig. Ein robuster Leser:

  • entpackt ein Member nach dem anderen;
  • behält jedes Byte, das er entpacken konnte, wenn der Stream abgeschnitten oder beschädigt ist, statt die Datei zu verwerfen;
  • prüft den CRC-32- und Größen-Trailer und meldet Abweichungen, ohne Daten zu verwerfen;
  • akzeptiert Daten, die bereits von einem anderen Tool dekomprimiert wurden (sie beginnen direkt mit einer Seiten-Magic).

Seitenheader

OffsetGrößeFeld
04Magic, gespeichert als ASCII-Bytes 1SLD, 2SLD oder 3SLD
44Unbekannt
84Seitengröße, u32 Little-Endian, gezählt ab dem Beginn des Headers

Seiten folgen aufeinander bis zum Ende der dekomprimierten Daten. Manche Beschreibungen nennen sie „DLS1/DLS2“, weil die Magic als Little-Endian-Ganzzahl gelesen so lautet; die Bytes auf der Platte sind 1SLD. Siehe DLS-Seite.

Datensätze

Nach dem Header folgen die Datensätze lückenlos aufeinander bis zur Seitengröße:

Feld1SLD2SLD3SLD
Pfad, UTF-8, NUL-terminiertjajaja
Event-ID, u64 LE+0+0+0
Flags, u32 LE+8+8+8
Node-ID, u64 LE+12+12
Zusatzfeld, 4 Bytes+20
Fester Teil nach dem Pfad12 Bytes20 Bytes24 Bytes
  • 2SLD erschien mit macOS 10.13 High Sierra, 3SLD mit macOS 14 Sonoma (laut den Implementierungsnotizen von FSEventsParser). Ein Volume, das über mehrere Upgrades hinweg genutzt wurde, kann mehrere Versionen enthalten.
  • Der Pfad ist relativ zum Stammverzeichnis des Volumes, so wie er zum Zeitpunkt der Protokollierung lautete: Users/dana/Library/LaunchAgents/com.example.updater.plist, nicht /System/Volumes/Data/Users/…. Leere Pfade kommen vor.
  • Das 3SLD-Zusatzfeld wird von FSEventsParser als vorzeichenbehaftete 32-Bit-Benutzer-ID (fs_uid) dekodiert und von mac_apt unbenannt gelassen. Apple hat es nicht dokumentiert; behandeln Sie jede Interpretation als Hypothese und testen Sie sie an bekannten Daten.
  • Die Flags behandelt die Flag-Referenz.

Defensiv parsen

Reale Sicherungen enthalten abgeschnittene, gecarvte und beschädigte Logs. Diese Regeln befolgt der Parser auf dieser Website:

  1. Eine Seite, deren angegebene Größe über die Daten hinausreicht, wird bis zum Ende der Daten analysiert und gemeldet.
  2. Ein Datensatz, dessen Pfad kein NUL hat oder dessen feste Felder nicht mehr hineinpassen, wird verworfen und gemeldet; die Datensätze davor bleiben erhalten.
  3. Null-Bytes nach dem letzten Datensatz oder der letzten Seite sind Slack, kein Fehler.
  4. Bytes, die keine Seiten-Magic sind, werden bis zum nächsten 1SLD/2SLD/3SLD übersprungen, und die Anzahl übersprungener Bytes wird gemeldet.
  5. Datensätze mit unmöglichen Flag-Kombinationen (sowohl File als auch Folder, sowohl Symlink als auch Hard link) werden als Anzeichen einer Beschädigung gezählt, wie es FSEventsParser bei gecarvten Daten tut.
  6. Pfade, die kein gültiges UTF-8 sind, werden mit Ersatzzeichen angezeigt und gezählt.

Zeitstempel

Das Format enthält keine. Wie man Datensätze anhand der Änderungszeiten der Logdateien zeitlich einordnet, beschreibt FSEvents-Datensätze zeitlich einordnen.

FAQ

Was ist der Unterschied zwischen 1SLD, 2SLD und 3SLD?

Die Datensatzgröße. 1SLD-Datensätze enthalten einen Pfad, eine 8-Byte-Event-ID und 4-Byte-Flags; 2SLD ergänzt eine 8-Byte-Node-ID (macOS 10.13 und neuer); 3SLD ergänzt 4 weitere Bytes (macOS 14 und neuer).

Sind FSEvents-Logs Little-Endian?

Ja. Seitengröße, Event-ID, Flags, Node-ID und Zusatzfeld sind alle Little-Endian gespeichert. Manche Tools lesen die Flags als Big-Endian und verwenden byteweise vertauschte Konstanten, was zu denselben Namen führt.

Verwandte Artikel