When you delete a file or copy data to an external drive, you rarely think about how exactly the operating system understands how much space an object takes up. For the user, these are just numbers in the properties, but at the physical level of a hard drive or SSD, size information is scattered across strictly defined sectors. Understanding where the size is indicated on a drive is critical for data recovery and digital forensics professionals.
The file system acts as a navigator that knows not only the coordinates of the beginning of the recording, but also its length. This information is not stored in one place, but is duplicated in several service structures to ensure integrity. If one pointer is damaged, the system can turn to a backup or analyze neighboring records.
In this article we will examine in detail the architecture of modern file systems, paying special attention to NTFS, since it is a standard for Windows. You will learn which bytes are responsible for the file length, how the cluster size is calculated, and why the actual disk space may differ from what Explorer shows.
Logical structure of the file system and the concept of a cluster
Before looking for specific bytes responsible for size, it is necessary to understand the minimum unit of space allocation. The operating system does not deal with individual bytes or bits when allocating disk space. Instead, the entire volume is divided into fixed-size blocks called clusters (or Allocation Units). It is in clusters that the space occupied by a file is measured.
The cluster size is set when formatting the partition and can vary from 512 bytes to 64 KB or more. NTFS the default is often 4 KB to balance space efficiency and access speed. If a file occupies 1 byte, it will still “eat” the entire cluster, and exactly this full volume will be recorded in the file allocation table.
- 📏 Minimum unit: A file cannot occupy less than one cluster, even if its actual size is negligible.
- ⚡ Impact on speed: Large clusters reduce the size of addressing tables and speed up reading of large files.
- 💾 Lost place: With a small cluster size, fragmentation is reduced, but the overhead on service structures increases.
It is important to distinguish between logical file size (the number of bytes of useful information) and disk size (the number of bytes actually reserved by the file system). The difference between them is called slack space or boring space. It is in this area that traces of deleted data often remain, which can be detected by in-depth analysis of the disk.
MFT table: the heart of the NTFS file system
On the file system NTFS All information about files, including their size, is stored in a special system file table known as Master File Table (MFT). This is not just a list of names, but a complex database, where each file or folder has an associated entry, usually 1024 bytes long. Inside this record are so-called attributes.
Attributes are structured blocks of data that describe various properties of an object. We are interested in the attribute with the code 0x20who bears the name $DATA. It is the header of this attribute that contains a field indicating the actual size of the data. For small files (typically up to 800 bytes), the content can be stored directly inside the MFT (resident data) record, and the size is then indicated in the attribute header.
If a file does not fit into an MFT entry, it becomes non-resident. In this case the attribute $DATA does not contain the data itself, but a list of clusters (Data Runs) where they are scattered across the disk. Even so, there are two key size values present in the attribute header: the actual size and the allocated size (rounded up to a cluster).
⚠️ Attention: If an MFT record is damaged, the operating system may lose information about the file size, even if the data itself is physically intact. In such cases, resizing requires manual content analysis or searching for MFT backups.
Size search in MFT is carried out by offset. For example, in the attribute header there is a field “Length of Resident Data” (for resident files) or “Allocated Length” (for non-resident files). These values are stored in hexadecimal format and occupy 8 bytes (64 bits), which allows them to support huge file sizes.
Data attribute structure and dimension fields
To accurately answer the question of where the size is indicated on the disk, you need to look inside the attribute structure $DATA. Each attribute begins with a header, which contains the attribute type, header length, and flags. Immediately following the title is the size information.
For resident files (located inside the MFT), the field Resident Data Length. It specifies the exact number of bytes of payload data. For non-resident files, the structure is more complex: there are two 64-bit values. The first is Real Size (actual data size), and the second is Allocated Size (allocated size in bytes, a multiple of the cluster size).
The difference between Real Size and Allocated Size is precisely the free space in the last cluster. The file system uses Allocated Size to control space allocation, and Real Size to know where the file actually ends up when read.
- 🔢 Real Size: The exact number of bytes of information written by the application.
- 📦 Allocated Size: The amount of disk space reserved for the file (rounded up to the cluster).
- 📍 Initial VCN: A field indicating the starting virtual number of the cluster, important for large files.
When analyzing the disk with a hex editor, you can see these values as a sequence of bytes. For example, the value 0A 00 00 00 00 00 00 00 in little-endian format will mean 10 bytes in size. Understanding the small-endian format for storing numbers is critical to correctly interpreting the data.
Partition size in partition table (MBR and GPT)
The size of the files themselves is not the only thing that interests the system administrator. Often the question “where is the size on the disk” refers to the size of the entire partition or disk. This information is stored in service areas preceding the file system. There are two main markup standards: MBR and GPT.
In the scheme MBR (Master Boot Record), which is located in the very first sector of the disk (LBA 0), the partition table starts at offset 0x1BE. Each partition entry takes 16 bytes. Inside this entry, starting from the 5th byte (offset 0x1C6 for the first partition), there are 4 bytes indicating the number of sectors in the partition. Multiplying this number by the sector size (typically 512 bytes) gives the full partition size.
Modern standard GPT (GUID Partition Table) uses a more robust structure. The GPT header is located in the second sector of the disk (LBA 1). It contains an array of 128 byte partition records. Each record contains the "Starting LBA" and "Ending LBA" fields. The difference between them, multiplied by the sector size, gives the exact partition size.
| Parameter | MBR (Legacy) | GPT (Modern) |
|---|---|---|
| Table location | Sector 0 (LBA 0) | Sector 1 (LBA 1) and end of disk |
| Max. partition size | 2 TB (limited) | 9.4 ZB (virtually unlimited) |
| Size field | 4 bytes (number of sectors) | 8 bytes (start and end LBA) |
| Reservation | No (MBR copy only) | Full copy of the header at the end of the disc |
Knowing the GPT structure is especially important when working with disks larger than 2 TB, since the MBR is simply not able to correctly display their full size. The operating system reads these values at boot and builds a map of the available space.
☑️ Checking the integrity of partitions
Hidden disk sizes and utility areas
In addition to explicit data about the size of files and partitions, there are areas on the disk whose size is often ignored by the user, but takes up space. These are service zones necessary for the operation of the journaling mechanism and shadow copies. B NTFS a significant part may be occupied by a file $LogFile and folder System Volume Information.
File $LogFile used to provide fault tolerance. Transactions are recorded in it before they are committed to the main table. Its size changes dynamically, but has a predefined maximum, which is also stored in file system service records. In the event of a sudden power outage, it is the analysis of this log that allows you to restore the integrity of the data.
⚠️ Attention: An attempt to manually resize service files (for example, through a hex editor) without understanding the structure of NTFS B-trees is guaranteed to result in loss of access to the entire partition.
It is also worth mentioning shadow copies (Shadow Copies). The system creates snapshots of the state of files, which can occupy up to 20% or more of disk space. Information about the size occupied by shadow copies is stored in the meta file $Extend\$Quota and special system files invisible in normal Explorer mode.
To analyze the actual distribution of space, including hidden areas, standard Windows tools may not be enough. Experts use utilities like WinHex or DMDE, which can read a disk sector by sector, bypassing the file system. This allows you to see the raw size of all structures, including unused space.
Practical methods for dimensional analysis and reconstruction
If you encounter a situation where the file size is displayed incorrectly or is zero, this often indicates that the attribute is corrupted $DATA in MFT. Restoring the size is possible using several methods. The first is heuristic analysis: programs scan the contents of clusters and try to find file signatures (headers) to determine the end of the data.
The second method is the analysis of neighboring records. If a file has been deleted, its MFT record may be marked as free, but the size information is often retained until it is overwritten. In a hex editor, deleted entries are marked with a byte 00 in the first byte of the entry, but the attribute structure remains readable.
To automatically correct size and cross-reference errors in the file system, Windows uses a utility chkdsk. Team
chkdsk X: /f- 🔍 Search for signatures: Finding magic numbers (for example,
50 4B 03 04for ZIP) helps determine the beginning and often the end of the file. - 🛠 Using Chkdsk: A standard tool for checking the logical integrity of dimensions.
- 💻 Hex analysis: Manual field checking in MFT for advanced users.
It is important to understand that restoring the size “at random” is dangerous. If you specify a size larger than the actual size, you will end up with garbage at the end of the file. If it is less, you will lose some of the data. Therefore, it is always better to rely on automatic recovery algorithms that analyze the context.
FAQ: Frequently asked questions
Why is the file size on disk always larger than its actual size?
This happens due to clustering. The file system allocates space in blocks (clusters). If the file is 1 KB and the cluster size is 4 KB, the file will be allocated 4 KB. The remaining 3 KB is called slack space and is not used for other files.
Is it possible to change the cluster size without formatting the disk?
No, the cluster size (Allocation Unit Size) is set only when formatting the partition. Changing this setting requires completely wiping the data and creating a new file system, or using third-party utilities to convert partitions without losing data (which is always risky).
Where is the disk size stored in GPT?
The GPT header (LBA 1) has a "Last Usable LBA" field that indicates the address of the last sector available for partitions. Multiplying this address by the sector size gives the maximum available capacity.
What are Resident and Non-resident files in NTFS?
Resident are very small files whose data is stored directly inside the MFT record. Non-resident (non-resident) - files whose data is too large for MFT and are stored in separate clusters on the disk, and only links to them are recorded in MFT.
How can I see the hidden size of shadow copies?
Use command line and command vssadmin list shadowstorage. It will show how much space is reserved and used by the system to store previous versions of files.