The NTFS file system uses the $Bitmap file to track vacant vs. in use clusters. As a cluster is either in use or not, it is represented by a zero or a one. A single bit per cluster is enough to store this information. It is literally nothing more than a collection of ones and zeros or a ‘bit array’. Although invisible to the end user, NTFS treats the $Bitmap as ‘just another’ file.
What the $Bitmap is about.
Although the $Bitmap is primarily meant for internal use by the Windows file system driver, it is also very useful for utility software.
The $Bitmap and Undelete Software
File undelete software can use the file to determine if clusters that were allocated to a deleted file are free or in use. If they are free then there is a good chance that a deleted file can be recovered intact. Since at this point in time, the clusters are not allocated to another file.
If one or more clusters are flagged as ‘in use’, then the recovered file will probably be corrupt as it contains some data from another file. Theoretically it is of course possible that the clusters allocated to our deleted file were overwritten by a file that itself was then also deleted. As a result the clusters will be flagged ‘free’ and yet the recovered file will be corrupt. The clusters will contain data from the second deleted file. So the method is not waterproof.
JpegDigger uses the Bitmap as well to tell used from unused clusters so that it can enable you to only carve unused space.
The $Bitmap and defragmentation Software
Defrag and disk optimization software also relies on the $Bitmap. The $Bitmap is a convenient source to draw a disk cluster map. A cluster map is used to display versus in use clusters. But more importantly, it helps the software to find a block of unused clusters large enough to contain the (fragmented) file to be moved in to.
For each file the defrag software needs to move, the $Bitmap is examined. A set of APIs that is referred to as the ‘Windows Defrag API’ offers a ‘call’ to get the $Bitmap (FSCTL_GET_VOLUME_BITMAP). The software now processes the Bitmap to determine where the file can be moved to in one ‘chunk’. It is possible that the situation on the disk has already changed when the software actually tries to move the file. In this case the move fails. The software then either skips to the next block of contiguous free clusters, or it gets the updated $Bitmap.
The Bitmap itself is treated by NTFS as just a file, although be it a meta file. Meta files are preceded by the ‘$’ character are normally not visible to the user.
Now note that the get volume bitmap API even works on file systems without an actual $BITMAP. Even on FAT and FAT32 volumes the API will return structure in which each bit represents the state of a cluster: in use / not in use.
Hey DiskTuna, I think we’ve chatted on some other data recovery forums.
I’m just curious, have you ever done any work to deconstruct how the windows $Bitmap actually keeps track of full/empty clusters? I know when it’s at 00 the cluster block is empty and at FF it’s full, but I’ve never quite figured out what it means when it’s another value like 7F or F0. Is it strictly using the binary 1 for full and 0 for empty? The size of the $Bitmap file leads me to believe that one byte is used to track 8 clusters.
I was thinking of making a python scripted tool for analyzing these files when looking for things like lost encrypted disk images that may be found only from analyzing the empty space.
Hi Jared aka Mr Data Medics,
Yes, one byte ‘tracks’ 8 clusters as to record two states we only need 2 values for which a bit is enough (o vs 1). So it’s a matter of converting the byte value to bits, eg. 00h = 00000000 to FFh = 11111111.