I'm using Windows 7 and NTFS. I've noticed the MFT is a huge security risk because it can store sensitive document files without user knowledge for a long time before they get overwritten.

All tests I've run tell me that files smaller than 640 bytes are resident in the MFT and cannot be securely deleted. However, any files that are 640 bytes or more can be securely deleted immediately - this is true for my 500GB HDD and my 128GB Flash Drive (both NTFS).

I've tested this by creating a bunch of text files and writing words to them to create different file sizes. Deleting them, emptying recycle bin and running Recuva and then securely deleting highlighted. It fails to securely delete any file under 640 bytes (file is resident in MFT message will come up).

Is this the same for SSDs with Trim Enabled? Why 640 bytes? Thought it was 512 bytes maximum for MFT entries for wiped files?

Any input much appreciated.

  • 1
    Regarding the "why"... NTFS file records are 1024kb. Some of this space is needed for required attributes such as $FILE_NAME, and you are left with the remainder for resident files. Mar 5, 2017 at 21:56
  • 2
    @AndreaLazzarotto the recode size is 1KB or 1024 bytes, not 1024KB
    – phuclv
    Jul 13, 2018 at 1:36
  • @phuclv holy smokes you are right. Damn typo. :o Jul 13, 2018 at 10:33

2 Answers 2


Any files can be deleted securely, as long as you use the correct tool. For example Sysinternals' SDelete is capable of handling this

On NTFS drives SDelete's job isn't necessarily through after it allocates and overwrites the two files. SDelete must also fill any existing free portions of the NTFS MFT (Master File Table) with files that fit within an MFT record. An MFT record is typically 1KB in size, and every file or directory on a disk requires at least one MFT record. Small files are stored entirely within their MFT record, while files that don't fit within a record are allocated clusters outside the MFT. All SDelete has to do to take care of the free MFT space is allocate the largest file it can - when the file occupies all the available space in an MFT Record NTFS will prevent the file from getting larger, since there are no free clusters left on the disk (they are being held by the two files SDelete previously allocated). SDelete then repeats the process. When SDelete can no longer even create a new file, it knows that all the previously free records in the MFT have been completely filled with securely overwritten files.

Surely you've chosen the wrong tool because if you've read the documentation you'd see that

Recuva cannot:

  • ...
  • Securely delete certain very small files that are held in the Master File Table (MFT) and files of zero-byte length.

Introducing Recuva - What it can and can't do

Why 640 bytes? Thought it was 512 bytes maximum for MFT entries for wiped files?

Size of files that can be stored in MFT (called resident files) varies depending on each file, each system and which information is stored in MFT. The more data is used for metadata in MFT, the less is left for the file, thus there's no defined limit, but according typically Files smaller than approximately 900 bytes are stored within the directory entry at the MFT

The figure MFT Entry with Resident Record shows the contents of an MFT record for a small file or folder. Small files and folders (typically, 900 bytes or smaller) are entirely contained within the file’s MFT record.

How NTFS Works

As an example I created an example 1000-byte file with very minimal metadata that can be stored completely in the MFT. But as soon as I added more metadata to the file (hard links, longer names, streams, permissions...) the maximum space that can accommodate the resident file quickly reduces

  • seems different file formats can have more bytes in the MFT than others then.. do SSDs with DRAZT or DRAT on trim command change any of the information stored in the MFT for those small files?
    – Jeff
    Mar 6, 2017 at 1:32
  • I don't know about DRAZT or DRAT but SSDs will remap sectors and/or move data for wear levelling so all bets are off. I believe the secure cleaning on remapping will be handled by the SSD firmware so on top of the OS you just need to use a cleaning tool just like on HDD
    – phuclv
    Mar 6, 2017 at 2:13

The MFT entry is 1024 bytes long (see the MFT section at http://www.cse.scu.edu/~tschwarz/coen252_07Fall/Lectures/NTFS.html) and stores more than just the filename - it also can include the file size, read/write permission, creation/modification date, and other meta-info. These items all have allocated sizes and this is why, in earlier versions of Windows, you could encounter an error if the filename was too long. This is also why you are unable to store files larger than 640 bytes entirely inside the table - the remaining 384 bytes (1024-640=384) were for the dedicated allocations.

It is useful to know that you computer has two identical MFT's, not one. The main is on the outer edge of the HDD, and the second one is located halfway in. The second one exists as a backup in case the main one is damaged, which can happen if the computer is shut off while an entry was being written or changed. Every MFT-cleaning program should delete from both tables (and the process is handled by the BIOS or the drive's firmware), but this is one thing to keep in mind if you want to take your data security to an extreme.

Also, the MFT row size CAN be varied, based on the drive (or partition) size and its intended purpose. Datacenters and servers are more likely to use a non-standard size, as the MFT allocation can be more than 10% of the HDD so the extra space becomes valuable. However, 1024 bytes is the standard.

  • as I said, any limit are wrong since it depends on the metadata size. But by default I an store files more than 900 bytes long in the MFT and not only 640 bytes
    – phuclv
    Nov 19, 2019 at 7:44
  • I think I covered that contingency in the last paragraph of my post - 1024 bytes is the standard metadata row size, but it can be set to a different size. Or is there some other aspect you are addressing? Nov 19, 2019 at 20:45
  • 2
    "your computer has two identical MFTs" ... "the main is on the outer edge" ... "second one is located halfway in" => Sorry to be blunt but this is BULLSHIT. MFTMirr is only a backup of the first 4 MFT records, and is located near the beginning of each partition (not one per computer, not even one per NTFS partitioned device), at sector 16, while the actual $MFT is located at the 3GB mark – starting with Win 7, it used to be different. This can be checked easily with WinHex for instance. See: superuser.com/questions/1332970 & thestarman.pcministry.com/asm/mbr/IntNTFSfs.htm
    – GabrielB
    Apr 9, 2022 at 23:30
  • 1
    I quickly checked the article you linked – the link is no longer valid but it can still be accessed here: tinyurl.com/mr2fjws6 – it seems highly technical at first glance, but it contains egregious errors as the ones I mentioned above, as well as egregious typos like "MTF" or "NTSF". The link I provided above is definitely a much better resource for anyone who wants to learn about NTFS in-depth.
    – GabrielB
    Apr 9, 2022 at 23:49
  • @GabrielB Thanks! You are correct regarding MFTMirr storing only the first 4 entries! I did a bit of digging on the other point - the physical locations of the MFT's, and there is some disagreement: assemblymade.com/2020/02/what-is-the-mftmirr-file states "$MFTMirr is usually located half way through the volume." BUT, your TheStarMan link mentions "$MFTMirr file located in the middle of the volume..." for Era 2, and that it's immediately after the Volume Boot Record in Era 3. So there is either outdated info or incorrect info out there. Fortunately, few of us need to know. May 20, 2022 at 18:30

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .