What does an NTFS $UsnJrnl entry recording a file's deletion prove, and what can it never show?

## What the change journal is NTFS maintains an update sequence number (USN) change journal in a metadata file named $UsnJrnl, whose $J data stream holds the records. Its purpose is not forensic -- it exists so that backup, indexing and replication software can ask "what changed since USN *n*?" without walking the whole volume. Forensics borrows it, which is exactly why it is so useful: it was written by the system for the system, with no attempt to describe intent. ## What one record contains A change-journal record carries, in essence: - **Usn** -- a monotonically increasing offset-like sequence number, which orders changes on the volume. - **TimeStamp** -- when the change was recorded. - **FileName** -- the name at the time of the change (not the full path). - **FileReferenceNumber** -- the identifier of the file's MFT record, with a sequence number that increments when the record is reused. - **ParentFileReferenceNumber** -- the identifier of the containing directory's record, which is how paths are reconstructed. - **Reason** -- a bitmask of what changed: file-create, data-extend, data-overwrite, data-truncation, rename-old-name, rename-new-name, basic-info-change, file-delete, close, and others. - **FileAttributes**, plus a security-descriptor index and source-info flags. There is deliberately **no content**, **no file size**, and **no user or process identity**. The journal answers "what changed about which file", never "what did it hold" or "who touched it". ## What you can legitimately conclude From a sequence of records you can state, with the artefact behind you: - A file with a specific name existed under a specific directory (resolve the parent reference through the MFT, or through other journal records for that reference number). - It was created at one time and deleted at another, giving a lifespan. - It was renamed, because a rename produces a paired rename-old-name and rename-new-name record for the same file reference number -- which is how you follow a file that was renamed before being copied out. - Data was written to it after creation, because data-extend or data-overwrite reasons appear -- so it was not merely an empty placeholder. That last point is the strongest one available: the journal can show that a named file *had bytes written into it*, without showing what those bytes were. ## What you cannot conclude - **Content.** Nothing in the journal touches file data. If the clusters are gone, the journal does not bring them back. - **Size.** There is no size field. A size can sometimes be recovered from a still-intact MFT record or a directory index entry, but it does not come from the journal. - **Actor.** No user SID and no process. Attributing the deletion to a person requires other evidence -- an interactive logon session covering that time, a lock/unlock trail, physical access records. - **Intent.** A delete looks identical whether it was an employee covering tracks, an application cleaning temporary files, or an installer removing its own staging directory. ## Why the horizon is short The journal is a fixed-size circular structure: as it fills, the oldest records are discarded from the front (the file is sparse, so old space is deallocated rather than shrunk). The default is small relative to a busy volume, so the practical horizon can be days rather than months -- and on a build server or a developer laptop with heavy file churn it can be hours. It can also be disabled or deleted by an administrator, and an absent journal is itself a fact worth recording, though absence is weak evidence on its own since not every volume has it enabled. ## Saying this out loud to non-technical people When an examination lands in an HR conversation, the subject's defence is often "that folder never held what you say it held". The disciplined position is to keep the two claims apart. "These records show a file named X existed in folder Y, had data written to it, and was deleted at 18:42 on that date" is what the artefact supports. "X contained the turbine design" is a separate claim that needs a separate artefact -- a backup, a copy on a server, a version-control history, an email attachment. If you do not have one, say so plainly rather than letting the strength of the first claim carry the second.