Where $MFT, $LogFile and $UsnJrnl Disagree

On an NTFS volume, three structures record file activity and they record different things. $MFT holds the current state of every file entry, including its timestamps, but no history. $LogFile holds a short, dense, transactional record of metadata changes. $UsnJrnl holds a longer, thinner stream of what changed and why. When they disagree, the disagreement is usually the finding.

What does $MFT actually record?

Every file and directory on an NTFS volume has at least one entry in the Master File Table. The MFT is itself a file — entry 0 — and so are the other metadata files: $LogFile is entry 2, and $UsnJrnl lives under the \$Extend directory. Entries are fixed size, conventionally 1,024 bytes, though the size is set at format time and should be read from $Boot rather than assumed.

An entry is a header plus a sequence of attributes. Three matter constantly:

• $STANDARD_INFORMATION — flags, owner and security id references, and four timestamps: file creation, last data modification, last MFT-entry modification, and last access. The conventional shorthand is MACB: Modified, Accessed, Changed (meaning the MFT entry changed), Born.
• $FILE_NAME — the name, the parent directory's file reference, and a second, independent set of the same four timestamps. There is one $FILE_NAME attribute per name the file has, so a file with an 8.3 short name and a long name has two, and a hard-linked file has one per link.
• $DATA — either the content itself, if it is small enough to sit inside the entry (a resident file), or the list of cluster runs where the content lives. A resident file's content is inside the MFT, which means a copy of $MFT alone can carry the full contents of small files.

The two timestamp sets are the single most productive disagreement in NTFS analysis, and the reason is mundane. The $FILE_NAME timestamps are written when the name is created and updated on operations that touch the name — creation, rename, move. They are not routinely rewritten every time the file's content changes. The $STANDARD_INFORMATION set is the one the operating system exposes and the one a program can set directly through documented Windows API calls. So a tool that rewrites timestamps normally rewrites $SI and leaves $FN alone, and the residue of the original chronology survives in the name attribute.

NTFS timestamps are 64-bit values counting 100-nanosecond intervals from 1 January 1601 UTC. That resolution is nominal, not real. The operating system updates file times in coarser increments than 100 nanoseconds, so genuine values carry noisy low-order digits; a value whose sub-second component is exactly zero across all four fields is worth a second look. Note also that last-access updating has been disabled by default on several Windows releases and its behaviour has changed across versions — read the NtfsDisableLastAccessUpdate value under HKLM\SYSTEM\CurrentControlSet\Control\FileSystem on the subject system rather than assuming the version's reputation.

What $MFT cannot establish

It is a snapshot. It tells you the last state of each entry, not the sequence that produced it. A file deleted and its entry reused is simply gone from the live view. A file whose timestamps were rewritten looks like a file with those timestamps. And an MFT entry marked unallocated persists, name and all, until NTFS reuses it — which means the presence of a deleted entry proves the name existed, but its absence proves nothing at all about whether it did.

What does $LogFile add that $MFT does not?

$LogFile is NTFS's metadata journal. Its purpose is crash consistency: before NTFS commits a metadata change it writes redo and undo information, so an interrupted operation can be completed or rolled back at mount. It is a circular buffer with a fixed size, scaled at format time to the volume — you can read and set that size with chkdsk /L.

For an investigator, three properties matter.

First, it is transactional: records carry log sequence numbers, so operations appear in order. Second, the redo data frequently contains complete or partial images of MFT entries and index entries, which means the journal can hold a previous version of a $STANDARD_INFORMATION attribute — the timestamps a file had before they were changed. Third, and decisively, its retention is short. On a busy Windows volume the buffer can wrap in hours. It is the richest of the three structures and the first to be gone.

That combination makes $LogFile a fast-response artifact. If the question is "what happened in the last few hours on this machine", it is often the best answer available. If the question is "what happened last quarter", it will not help you, and saying so early saves everyone time.

Tooling is thinner here than elsewhere. Joakim Schicht's LogFileParser is the long-standing open-source parser. Note that MFTECmd, part of Eric Zimmerman's tools, parses $MFT, $J, $Boot and $SDS but not $LogFile — a distinction worth getting right before you promise a court a $LogFile analysis.

What does $UsnJrnl contribute?

The update sequence number change journal lives at \$Extend\$UsnJrnl and has two named data streams: $Max, holding the journal's configuration, and $J, holding the records. $J is a sparse file: as the journal advances, older regions are deallocated rather than rewritten, so a logical read returns zeroes for the trimmed portion and the useful data must be extracted from the allocated regions.

Each record carries an update sequence number, a timestamp, the file's 64-bit file reference number, its parent's file reference number, the name, and a set of reason flags describing what changed — a file being created, deleted, renamed (recorded as separate old-name and new-name events), data overwritten, extended or truncated, basic information changed, security changed, and a close event. Because the reason flags accumulate across a file's open session and flush on close, one action can appear as several records.

$UsnJrnl is therefore the best available narrative of file activity: it names things, it says what class of change occurred, and it survives considerably longer than $LogFile because each record is small. Its maximum size and allocation delta are configurable and are set by Windows relative to the volume; read them from the subject system with fsutil usn queryjournal rather than relying on a published default. Real-world coverage is typically days to weeks, and on a lightly used volume can be much longer.

What $UsnJrnl cannot establish

It records that a change occurred, not what the content became. There is no file size, no hash, no content, no user account in a USN record. It cannot distinguish a one-byte edit from a complete rewrite. And because an entry's file reference number encodes both an MFT record index and a sequence number that increments on reuse, a USN record for a since-recycled entry can be positively excluded from the current file at that index — useful, but it means the trail ends there.

Where do the three structures disagree, and what does that tell you?

Question	$MFT	$LogFile	$UsnJrnl
Does the name exist now?	Yes	No	No
What order did events occur in?	No	Yes	Yes
What were the previous timestamps?	No	Sometimes	No
Was the file deleted, and when?	Only if the entry survives	Yes, briefly	Yes, for longer
What did the content become?	Current state only	No	No
How long is the window?	Live volume	Hours	Days to weeks

Four disagreements recur.

A deleted file with no MFT entry. The entry has been reused, so $MFT says nothing existed. $UsnJrnl still holds the create, the writes and the delete, with the name and parent reference. This is the most common reason to parse $J at all.

$SI earlier than $FN. A file whose $STANDARD_INFORMATION creation time precedes its $FILE_NAME creation time is chronologically impossible on a single volume without intervention: the name cannot be younger than a file created after it. Before calling it timestamp manipulation, exclude the benign causes — archive extraction restores stored modification times, installers set times deliberately, and files copied from another volume or restored from backup arrive with times from elsewhere.

A file whose $SI says 2019 sitting in a high MFT record among files from this year. MFT records are allocated roughly in order and reused from the lowest free index. A very old creation date in a very new record is an anomaly to explain, not a conclusion.

A change with no corresponding modification. A $J record noting basic information changed, with no accompanying data overwrite or extension, is the signature of something setting timestamps or attributes rather than editing content — and that record carries the journal's own timestamp, taken from the system clock at the time of the write. That is the value: the manipulated timestamp lives in $MFT, and the real wall-clock moment of the manipulation lives in the journal.

What does none of this establish?

This is the part that decides whether a timeline survives cross-examination.

• Account, not person. NTFS structures carry security identifier references, not people. Nothing in $MFT, $LogFile or $UsnJrnl places a human at a keyboard.
• Access, not reading, and certainly not exfiltration. A last-access time — where access updating is even enabled — can be set by antivirus scanning, content indexing, backup software, or an examiner who mounted the volume read-write. A file being read is not a file being understood, and a file being copied within a volume is not a file leaving it.
• A copy is not the same as a creation. When Windows copies a file, the destination is created now and commonly inherits the source's last-write time, producing a file whose creation time is later than its modification time. That pattern is a strong indicator of a copy, and it is the reason a creation timestamp should never be described as "when the document was written".
• Absence is not absence. $LogFile wrapping, $J trimming and MFT entry reuse are all routine. "There is no record of the deletion" and "the deletion did not happen" are different statements, and only the first one is yours to make.
• Filesystem time is one layer. An application's own record of an event — a browser history row, a message database, a document's internal properties — is a different assertion by a different clock. Filesystem timestamps tell you about the container.

Other filesystems do not offer this structure, and assuming they do is a recognisable error. ext4 stores a creation time in the inode where the inode format is large enough, but it is not exposed by ordinary tooling and there is no equivalent to the USN journal; APFS has no comparable published change journal. A method written for NTFS is a method for NTFS.

Where to go deeper

Brian Carrier's File System Forensic Analysis remains the reference for the on-disk structures themselves, and it is worth reading the NTFS chapters with a hex editor open. The Sleuth Kit and Autopsy implement much of it and can be checked against it. For building the combined timeline rather than parsing one structure, Plaso will ingest $MFT and $J alongside everything else and normalise the output, and Timesketch is where the result becomes reviewable by more than one person. Harlan Carvey's Investigating Windows Systems works through the reasoning on real images rather than the format specifications, which is the harder half. Validate your parsers against known data — the CFReDS images exist for exactly this — and record which tool version produced which finding, because ISO/IEC 27041 is about being able to show your method was fit for the question.

Where timelines get argued in court, the argument is usually about foundation rather than parsing. United States v. Durham is a useful frame for the distinction courts draw between evidence that is unique and readily identifiable and evidence that is susceptible to alteration and so demands a fuller chain. And Cat3, LLC v. Black Lineage is what it looks like when metadata analysis shows that the produced version of a record is not the original one.

If you want structured practice on these artifacts specifically, 13Cubed covers NTFS internals in depth, and the Windows forensics certifications — GCFE and GCFA — both test them.