Jaa

NTFS MetaFiles

  • Artikkeli

They sit there, hiding in the root directory…metafiles. The shell hides them from the user, but they are still there…lurking. Microsoft does a pretty good job hiding these files so you don’t accidentally damage them. But what are these files and how does NTFS use them?

Before we have a look at them I’d like to issue a warning…

WARNING!!! Do NOT try to alter or delete these files. Doing so can and will cause permanent damage to your file system. And more than likely CHKDSK won’t be able to save you. You will lose all your data if you ignore this warning.

Hopefully you are now sufficiently scared.

If you haven’t already done so I recommend you read my blog entitled “The Four Stages for File Growth” to give you a better idea of how files are stored on your hard drive. It isn’t required for understanding this blog but it would help.

Now let’s have a look at these elusive files.

File 0 - $MFT: Not to be confused with the actual MFT (Master File Table), the $MFT tells us where all the pieces of MFT are. The MFT is part of the $MFT file. And the $MFT file is contained within the MFT. It’s this whole ‘chicken and the egg’ thing.

$MFT – A file in the Master File Table (MFT)

MFT – The table that contains all file records

What makes it confusing is that the entire MFT is in the $MFT file and the file record for $MFT is found in the MFT. They are separate structures but each one contains the other.

File 1 - $MFTMirr: This file tells us the location of a backup of the first few files in the MFT. In data recovery situations, where the beginning of the MFT is damaged, this mirror can help save the day. I’ve used it a number of times myself.

File 2 - $LogFile: This is simply a journal of the NTFS’s metadata transaction. Like most metafiles, it is not human readable and not meant for use by the user. Corruption of this file can cause you not to be able to mount the file system. This can be easily fixed by simply resizing the file. These two commands can assist with that….

Chkdsk <drive:> /L

(to find out the current size for $LogFile)

Chkdsk <drive:> /f /L:<new size>

(to resize$LogFile)

File 3 - $Volume: This file keeps record of the NTFS version, volume information, and the volume label. So if you name your volume ‘DAVE’, this is the file that stores that information

clip_image002

File 4 - $AttrDef: The $AttrDef file defines the different attributes that the file system can have. Here is a list of the attribute types available:

$STANDARD_INFORMATION

$ATTRUBUTE_LIST

$FILE_NAME

$VOLUME_VERSION

$OBJECT_ID

$SECURITY_DESCRIPTOR

$VOLUME_NAME

$VOLUME_INFORMATION

$DATA

$INDEX_ROOT

$INDEX_ALLOCATION

$BITMAP

$SYMBOLIC_LINK

$REPARSE_POINT

$EA_INFOMRATION

 

$LOGGED_UTILITY_STREAM

 

 

NOTE: Do not confuse file attributes like $DATA and $FILE_NAME with attributes like READ-ONLY, SYSTEM, or HIDDEN (which are actually just flags).

File 5 – (.): The dot (.) is the root directory for the volume. So when you do a ‘dir’ of c:\, you are looking at the dot (.).

File 6 - $Bitmap: This file keeps track of all the clusters of the volume and whether or not each cluster is currently in use. That’s how we can quickly determine how much free space you have. We just ask $Bitmap.

File 7 - $Boot: Contains boot sector and the boot strap (the first 16 sectors of the volume). The boot sector contains the location of the $MFT and $MFTMirr. Otherwise we wouldn’t know where to look for them.

clip_image004

In the image above, all parts of the $BOOT file are shown in RED. The file starts in the MFT and points back to the beginning of the volume for its $DATA attribute, which contains the boot strap. It is this boot strap code that tells us what boot loader we are using (NTLDR for Windows XP/Windows 2003 and BOOTMGR for Vista/Windows 2008). Also the boot sector tells us the location of the MFT. This is part of how Windows is able to locate files during the early stages of bootup, before the NTFS.SYS driver actually loads.

File 8 - $BadClus: Keeps a record of the clusters on your volume that contain physically bad sectors. We mark them bad so we don’t try to use them. If you ever run CHKDSK with a /r switch, then you are telling CHKDSK to update $BadClus with any new bad sectors that are found.

File 9 - $Secure: Contains security information. For obvious reasons, I’m not going to tell you how it works.

File 10 - $UpCase: This file contains the casing table.

Trivia – For the young folks that don’t know, the terms upper case and lower case came about with the early printing presses that kept the capitol letters in the upper drawer or case, while the more often used small letters were stored in the closer, lower case.

File 11 - $Extend: A directory that can house files used for optional extensions.

That’s about it. Microsoft reserves space in case we want to add any additional files. So you won’t start seeing normal files until File 17.

Robert Mitchell
Senior Support Escalation Engineer
Microsoft Enterprise Platforms Support

Demystifying NTFS as much as I’m allowed to

Comments

  • Anonymous
    January 01, 2003
    Thanks for the comments.  I've actually been thinking of doing a blog on SSD.  It would be a while before I get to it.  I have a pretty long list of blogs to complete.
  • Anonymous
    January 01, 2003
    Yes.  FSCTL_GET_VOLUME_BITMAPmsdn.microsoft.com/.../aa364573.aspx
  • Anonymous
    December 03, 2010
    Excellent explanation !!!  I would also request you to blog something on SSD architecture as well.
  • Anonymous
    January 13, 2011
    SSD architecture and how they work has been documented very well on Anandtech's web site.The SSD Anthology: Understanding SSDs and New Drives from OCZwww.anandtech.com/.../1
  • Anonymous
    September 28, 2011
    BTW is there any API to read for example $BOOT file into memory?
  • Anonymous
    November 08, 2013
    Great Articles. Serves the purpose. :)
  • Anonymous
    March 26, 2014
    BOOL DeviceIoControl(
    (HANDLE) hDevice, // handle to volume
    FSCTL_GET_VOLUME_BITMAP, // dwIoControlCode
    (LPVOID) lpInBuffer, // input buffer
    (DWORD) nInBufferSize, // size of input buffer
    (LPVOID) lpOutBuffer, // output buffer
    (DWORD) nOutBufferSize, // size of output buffer
    (LPDWORD) lpBytesReturned, // number of bytes returned
    (LPOVERLAPPED) lpOverlapped // OVERLAPPED structure
    );

    The above was referred by Robert Mitchell.
    Is it true that lpOverlapped concerned with "overlay" in loader layouts?
  • Anonymous
    March 26, 2014
    Hi
    1.If the bitmap image content is missing?
    2.what does it mean?
    3.how to rectify?
  • Anonymous
    August 06, 2015
    If the metafile, $BITMAP, is missing or damaged in some way, running chkdsk /f will generate a new one.