Jusqu'où remonte le $LogFile ? Limites et pièges

Q: Peut-on faire garder plus d'historique au $LogFile ?

Oui, comme mesure de préparation avant un incident : chkdsk /L:taille change la taille du journal d'un volume NTFS. Un journal plus grand garde plus d'historique. Ne le faites pas sur un volume que vous vous apprêtez à acquérir comme preuve, puisque cela modifie le journal.

TL;DR. Le $LogFile est un tampon circulaire d'environ 64 Mio sur la plupart des volumes actuels. Sur un disque système chargé, cela représente de quelques minutes à quelques heures d'historique ; sur un disque secondaire ou amovible, parfois bien plus. Outre la rétention, il a quatre angles morts structurels : pas d'heure d'horloge, des noms seulement quand ils changent, des métadonnées uniquement (pas de contenu non résident) et une grande fragilité (chkdsk, ntfs-3g et votre propre activité le réécrivent). Les parseurs divergent aussi sur des détails. Utilisez-le pour la dernière fenêtre d'activité, avec le journal USN, le $MFT et les clichés instantanés.

Rien de tout cela ne le rend moins utile. C'est un instrument précis à courte portée, et les rapports qui oublient cette portée se font contester.

Rétention : à quoi ressemblent les chiffres

Facteur	Effet
Taille du journal	Généralement autour de 64 Mio sur les volumes Windows actuels ; `chkdsk /L` l'affiche ou la modifie (Microsoft Learn). Les volumes anciens ou petits peuvent avoir moins — l'exemple chkdsk de Microsoft affiche 22 544 Ko (KB 814594)
Activité sur les métadonnées	Chaque création, renommage, suppression, modification d'attribut ou d'index consomme de l'espace de journal. Navigateurs, mises à jour, analyses antivirus, indexation et SRUM génèrent tous de l'activité
Rôle du volume	Les volumes système sont les plus sollicités ; les volumes de données et amovibles, les moins
Points de contrôle	Les dumps de tables écrits à chaque point de contrôle consomment aussi de l'espace

Observations publiées :

Maxim Suhanov a mesuré le délai d'écrasement des anciennes données sous Windows 10 : 16 minutes dans un test, 5 h 20 dans un autre (How the $LogFile works?).
Le readme de LogFileParser de Joakim Schicht prévoit quelques heures sur un disque système très utilisé, et beaucoup plus sur des disques externes ou secondaires.
TZWorks décrit quelques heures d'activité en usage normal pour un journal de 64 Mo (mala).

Prenez-les comme des ordres de grandeur. Le seul chiffre fiable est celui de votre preuve : la plage de LSN donnée par le parseur et l'événement daté le plus ancien.

Obtenir plus d'historique

Collectez tôt. Avant le tri gourmand en mémoire, avant de copier des outils sur la machine.
Tous les volumes. Une clé USB ou un volume de données peut encore contenir la veille.
Clichés instantanés (VSS). Chaque cliché contient un $LogFile plus ancien. Parsez-les tous et étiquetez-les avec l'heure du cliché.
Préparation. Sur les systèmes que vous administrez, un journal plus grand (chkdsk C: /L:<taille en Ko>) garde plus d'historique. Le readme de LogFileParser donne chkdsk D: /L:2097152 comme exemple pour 2 Go. Testez d'abord l'impact sur les performances, et ne faites jamais cela sur un système que vous vous apprêtez à acquérir.

Angle mort 1 : pas d'horloge

Les enregistrements LFS portent des LSN, pas des heures. Toute heure affichée par un parseur vient des données journalisées :

Événement	Source de l'heure	Fiabilité
Création	Création `$FILE_NAME` dans l'enregistrement FILE ou l'entrée d'index	Bonne
Renommage / déplacement	Modification `$FILE_NAME`	Bonne
Modification `$SI`	Nouvelle valeur `$SI`	Bonne, sauf antidatage (timestomping)
Suppression	Dernière date connue du fichier	Borne inférieure seulement
Tout le reste	Voisin daté le plus proche (≈)	Approximative

C'est pour cette raison que le parseur de $LogFile dans le navigateur indique pour chaque événement la source de son heure. Pour des heures exactes, corrélez avec $UsnJrnl:$J (parseur de journal USN) et comparez les artefacts.

Angle mort 2 : les noms ne sont pas toujours là

La plupart des enregistrements désignent une entrée MFT, pas un fichier. Les noms apparaissent quand une entrée d'index est ajoutée ou retirée (création, renommage, suppression) ou quand un enregistrement FILE complet est écrit. Une modification d'horodatage sur un fichier créé la semaine dernière arrive avec un simple numéro d'entrée. Le $MFT du même volume résout le reste ; sans lui, les chemins commencent par [MFT #n]. Si le $MFT a été collecté après le journal, des entrées réutilisées peuvent se résoudre avec de mauvais noms — vérifiez les numéros de séquence.

Angle mort 3 : des métadonnées uniquement

Le contenu non résident des fichiers ne passe jamais par le journal.
Les petits fichiers résidents peuvent apparaître dans des images d'enregistrements FILE ou des créations d'attributs. La documentation de LogFileParser ajoute que, sur les Windows récents, les modifications ultérieures de données résidentes ne sont généralement pas journalisées avec leur contenu.
Les lectures de fichiers ne sont pas journalisées (les mises à jour de la date de dernier accès sont des métadonnées, mais souvent désactivées ou différées).

Angle mort 4 : il se détruit facilement

Votre propre activité. Chaque fichier écrit sur le volume de preuve ajoute des enregistrements.
chkdsk. Peut modifier ou redimensionner le journal ; une page de redémarrage signée CHKD le trahit.
ntfs-3g sous Linux. Lorsqu'on lui demande de monter, avec son option de récupération, un volume qui n'a pas été fermé proprement, ntfs-3g « vide » le journal en le remplissant de 0xFF (ntfs_logfile_reset dans libntfs-3g). Attachez toujours la preuve en lecture seule.
Coupure brutale ou arrêt propre. Un arrêt propre sous Windows 8+ réécrit le journal en version 1.1 (versions du format) ; un plantage laisse les pages rapides 2.0 en place. Aucun des deux ne détruit d'enregistrements en soi, mais ils changent l'emplacement de la page la plus récente.

Angle mort 5 : les parseurs divergent

Le format n'est documenté que par rétro-ingénierie. Les différences réelles entre outils portent notamment sur :

la fusion ou non des pages de queue / rapides, et la manière de le faire ;
le côté (redo ou undo) qui contient l'entrée lors d'une suppression d'index ;
la structure des entrées de la table des attributs ouverts ;
le regroupement des enregistrements en actions (transactions ou proximité) ;
les mises à jour partielles de $SI.

Le parseur dans le navigateur est transparent sur son propre statut : il est validé sur des journaux synthétiques construits à partir des structures publiées (Linux ntfs3, libfsntfs, dfir.ru), pas encore sur un corpus de journaux Windows réels. Il regroupe par entrée MFT dans une fenêtre d'enregistrements plutôt que par transaction, suppose $SI à l'offset 0x38 quand la structure de l'enregistrement est inconnue, ne suit pas les listes d'attributs et ne vérifie pas les numéros de séquence lors de la résolution des chemins via le $MFT. Confirmez les constats importants avec un second outil — voir le comparatif des parseurs de $LogFile.

Écrire les limites dans le rapport

Une phrase par constat suffit :

Le journal de transactions NTFS couvre les LSN 115720 à 117880 ; l'événement daté le plus ancien est à 09:58:12 UTC. L'activité antérieure n'est pas représentée dans cet artefact. Les enregistrements du journal ne portent pas d'horodatage ; les heures indiquées proviennent des horodatages du système de fichiers contenus dans les enregistrements, comme précisé pour chaque événement.

Questions fréquentes

Jusqu'où remonte le $LogFile NTFS ?

Cela dépend de sa taille et de l'activité. Le journal est circulaire et fait généralement environ 64 Mio ; sur un volume système chargé il couvre de quelques minutes à quelques heures, sur un volume de données ou amovible peu actif bien davantage. Des tests publiés sous Windows 10 ont vu les anciennes données écrasées au bout de 16 minutes dans un cas et de 5 h 20 dans un autre.

Peut-on faire garder plus d'historique au $LogFile ?

Oui, comme mesure de préparation avant un incident : chkdsk /L:taille change la taille du journal d'un volume NTFS. Un journal plus grand garde plus d'historique. Ne le faites pas sur un volume que vous vous apprêtez à acquérir comme preuve, puisque cela modifie le journal.