Cómo datar registros FSEvents sin marcas de tiempo

En resumen. Un registro se escribió en su archivo de log entre la fecha de modificación del archivo anterior y la fecha de modificación de ese mismo archivo. Esa ventana, junto con el orden que dan los ID de evento, es lo que FSEvents puede decir sobre el tiempo. Todo lo demás (una ruta con fecha, una marca de tiempo de APFS, una entrada del Unified Log) es correlación. Informe con rangos y nombre su punto de anclaje.

Por qué no hay marca de tiempo

Cada registro contiene una ruta, un ID de evento, flags y (en las versiones más recientes) un node ID. El ID de evento es un contador, no un reloj. Las únicas horas disponibles son los metadatos del sistema de archivos de los propios archivos de log y de fseventsd-uuid.

El método de la ventana

fseventsd acumula los eventos en memoria y los añade al archivo de log actual, abriendo un archivo nuevo de vez en cuando. Por tanto, para los archivos de log de un volumen, ordenados por ID de evento:

• la fecha de modificación de un archivo es el momento en que se volcaron sus últimos registros: un límite superior para todos los registros que contiene;
• la fecha de modificación del archivo anterior corresponde aproximadamente al momento en que comenzó este archivo: un límite inferior;
• para el archivo más antiguo, la fecha de modificación de fseventsd-uuid (cuando empezó este historial) es el único límite inferior, y puede ser meses anterior.

Ejemplo tomado de la muestra incluida con el FSEvents Parser:

Un LaunchAgent creado en el tercer archivo se escribió entre las 10:09:55 y las 10:23:18 UTC. Esa es la afirmación que debe hacerse, no "a las 10:23:18".

Cómo acotar la ventana

• Orden de los eventos. Dentro de una ventana, los registros están ordenados. Si el registro del LaunchAgent aparece después de un cambio en las preferencias de Terminal y antes de una escritura en TCC.db, y cualquiera de ellos puede datarse por otra vía, la ventana se reduce.
• Rutas con fecha. Los logs rotados, los informes de diagnóstico y los snapshots suelen llevar una fecha en el nombre (…-2026-09-14-091214.ips). Cuando una de esas rutas aparece como Created, sirve de anclaje para los ID de evento cercanos. FSEventsParser usa un conjunto de rutas conocidas para su columna de fecha aproximada; el FSEvents Parser muestra como pistas, para cada archivo de log, las fechas que encuentra en las rutas creadas.
• Otros artefactos. Las fechas de creación y modificación de APFS del elemento si todavía existe, los eventos de cuarentena para las descargas, los Unified Logs para las cargas de launchd y las filas de TCC.db con sus propias marcas de tiempo.

Cuándo falla el método

• Copiado sin conservar fechas. Un arrastre en Finder a ciertos destinos, AirDrop, el correo electrónico o una subida descuidada asignan a cada archivo la hora de la copia. Síntoma: todos los archivos de log comparten prácticamente la misma mtime. El parser lo señala y las ventanas deben ignorarse; el orden sigue siendo válido.
• mtimes desordenadas. Un archivo cuya mtime es anterior a la de su predecesor (cambios de reloj, archivos modificados con touch, herramientas que reescriben archivos). Ese archivo se queda sin límite inferior.
• Horas locales en ZIP. ZIP guarda las horas sin zona horaria salvo que incluya el campo de marca de tiempo extendida; una recopilación comprimida en una zona y leída en otra desplaza todas las ventanas según la diferencia horaria. Es preferible tar.gz.
• Largos periodos de inactividad. En un equipo que permanece en reposo durante días, una ventana puede abarcar varios días; el límite superior sigue siendo fiable.
• El log actual. El archivo más reciente puede seguir abierto en el momento de la recopilación; su mtime es la hora de la recopilación o la del último volcado.

Filtrar por tiempo

Dos preguntas distintas requieren dos filtros distintos, que el rango temporal del parser ofrece como campo de tiempo:

• Ventana aproximada (solapamiento): conserva un registro si su ventana se solapa con el rango. No se pierde nada que pueda estar dentro del rango; pueden incluirse algunos registros que queden fuera.
• Escritura del archivo de log (límite superior): conserva un registro si la mtime de su archivo está dentro del rango. Es más preciso, pero se pierde un registro escrito justo antes de un volcado que quede fuera del rango.

Use el primero para ser exhaustivo y el segundo para centrarse. En ambos casos, el rango se aplica a todas las vistas, recuentos, hallazgos y exportaciones, y se guarda en la URL (#from=…&to=…), de modo que un enlace compartido vuelve a abrir la misma ventana.

Preguntas frecuentes

¿Qué precisión tiene una ventana temporal de FSEvents?

La del intervalo entre dos volcados de archivos de log: normalmente de minutos a horas en un Mac activo, y mucho más amplio en uno inactivo. Es un rango, nunca un instante.

¿Y si todos los archivos de log de FSEvents tienen la misma fecha de modificación?

Casi con seguridad se copiaron sin conservar las fechas. El orden de los registros sigue siendo válido, pero las ventanas carecen de sentido; vuelva a recopilarlos con tar, ditto o UAC, como se describe en la guía de recopilación.