The short answer: $LogFile records the transaction metadata for every filesystem operation: file name, parent directory, operation type, timestamps plus the security identifier of the process performing the operation. It does not generally recover the deleted file content but it is the source of truth for what was deleted plus when plus by whom.
What the $LogFile Actually Is
Microsoft documentation describes $LogFile as the NTFS write-ahead log: every transaction is written to the journal before it commits to the live filesystem. The journal lives at \$LogFile in the root of every NTFS volume. It is a system file not visible through Windows Explorer but accessible through forensic acquisition tools plus low-level disk access APIs. The default size on modern Windows installations is approximately 64 MB managed as a circular buffer: when the journal fills, the oldest entries are overwritten by new transactions.
The transaction records inside $LogFile follow a documented format. Each record contains a log sequence number, a redo operation, an undo operation plus the file reference for the target object. The redo operation is the action that committed to the live filesystem. The undo operation is the rollback the journal would apply if a crash interrupted the transaction. Both fields contain enough metadata for a forensic examiner to reconstruct what happened during a specific filesystem operation.
What the $LogFile Shows for File Deletions
For a file deletion the $LogFile preserves several distinct records. There is the DeleteFile redo record showing the moment the master file table entry was marked for delete. There is the UpdateNonresidentValue record for parent directory updates when the deleted file is removed from the directory index. There is the SetIndexEntryVcnAllocation record for index defragmentation. There is also the cluster bitmap update showing when the file content blocks were released back to the free pool. Each record carries a timestamp accurate to within filesystem resolution (typically 100 nanosecond intervals on modern Windows).
For a forensic examiner asking the question of when a file was deleted, the $LogFile entries collectively answer that question with high precision. The delete timestamp from the master file table update is the authoritative answer plus the supporting records (directory index update, cluster bitmap update) provide corroborating timeline detail that strengthens evidentiary value in litigation contexts.
What the $LogFile Does Not Show
The $LogFile records transaction metadata not file content. When a deleted file is removed from the filesystem, the content blocks are not copied into the journal: they are simply released back to the cluster allocation bitmap. The deleted content can sometimes be recovered through carving the released clusters before they are overwritten by new files but that recovery is a separate operation from $LogFile analysis.
The $LogFile also does not show user identity by default. The process security identifier in the transaction record identifies the SYSTEM context or the user context at the kernel level but it does not record the human-readable user name. Correlating the SID to a user identity requires looking at the Windows registry SAM hive or Active Directory records. The correlation is straightforward in practice but it is a separate step in the investigation chain.
How Investigators Read the $LogFile
The standard tool for $LogFile parsing in Windows forensic investigations is the LogFileParser utility from the Joachim Metz NTFS toolset. The Joachim Metz parser reads the raw journal format plus emits a per-record CSV summary suitable for ingestion into a timeline tool. SANS DFIR community materials document the parser workflow in detail plus Eric Zimmerman's tooling (LECmd, MFTECmd, LogFileParser) provides Windows-native binaries for the same workflow.
For incident response engagements the Sherlock Forensics workflow combines $LogFile parsing with Windows event log analysis from the Sherlock Ultimate Event Viewer. The two artifacts together let an investigator answer questions like which user account was logged in at the moment of a specific file deletion plus what session that user was running. The $LogFile gives the filesystem-level truth, the event log gives the session-level context plus combining the two produces a defensible reconstruction.
Practical Limits Investigators Should Understand
The retention window for $LogFile is the most important practical limit. On a busy filesystem with heavy write activity, the 64 MB circular buffer may only cover the last few hours of activity. Modern enterprise file servers can churn through the entire journal in under an hour. On the other end of the spectrum, a workstation that is mostly idle can preserve weeks of journal history. The first triage question for any $LogFile-based investigation is whether the time window of interest still falls within the journal retention depth.
Volume Shadow Copy snapshots preserve historical $LogFile state at the moment of snapshot creation. If a Windows system has VSS snapshots enabled the older $LogFile state may be recoverable from the snapshot plus the effective retention window can extend backward by days or weeks depending on the snapshot schedule. Investigators triaging a long-tail incident should always check for VSS snapshots before concluding that the relevant journal window is gone.
The $LogFile is one of the strongest filesystem-level forensic artifacts on Windows but it is also one of the most time-sensitive: every minute of normal filesystem activity erodes the retention depth. Acquire the volume early plus preserve a forensic image before doing any in-place analysis.