Which NTFS artifact can prove that a file existed even if both its MFT entry…

NTFS maintains several special "$" metadata files outside of ordinary file records in the Master File Table (MFT). Structural bookkeeping files such as $Secure, $Volume, and $AttrDef each describe the volume as a whole - security descriptors, volume-level flags, and the attribute schema - and are simply updated in place with no per-file history. In contrast, the USN Change Journal ($UsnJrnl, via its $J data stream) is an append-only transactional log: it records file-system change events - creation, deletion, renaming, and other updates - and an entry can carry the filename, MFT reference number, timestamp, and a reason code for that change, so a journal entry can survive even after the file's own MFT entry is later reused and overwritten.

1. A file "invoice.docx" is created; NTFS logs a $UsnJrnl entry (reason flag: file created) that records the filename "invoice.docx" and its MFT reference number (say, entry 1234) at that time.

2. The file is later deleted; NTFS logs a further $UsnJrnl entry (reason flag: file deleted) associated with the same file, again carrying its filename and MFT reference.

3. Time passes and MFT entry 1234 is reused for an unrelated new file; the old filename and metadata that were inside that MFT entry are now completely overwritten.

4. The earlier $UsnJrnl entries live in a separate journal stream and are unaffected by the MFT entry's later reuse, so an examiner who parses the $J stream - while the relevant entries have not yet rolled off the size-capped journal - can still recover the filename "invoice.docx" and establish that the file once existed, even though its MFT entry and filename are now gone. (NTFS may combine several reason flags into one journal entry rather than always writing a separate entry per operation, but each entry remains independent of the MFT record either way.)

Checking each option by its own role confirms this:

• $Secure stores the volume's unique security descriptors (access-control and ownership information), each one deduplicated and referenced by ID across many files, with no per-file creation or deletion timeline.

• $Volume holds volume-wide metadata - the NTFS version, volume label, and the dirty-bit flag - describing the volume as a whole rather than any individual file's history.

• $AttrDef lists the attribute types the file system supports and the rules governing them, acting as a schema definition for the whole volume rather than a record of any particular file.

• $UsnJrnl is the only one of the four built as a change-journal log of individual file-system events, independent of the MFT entry those events originally referenced - which is what lets it establish a file's past existence after that MFT entry is overwritten.