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.