Exploring the NTFS File Recovery Algorithm
Discover the essential guide to understanding the NTFS file recovery algorithm in this comprehensive tutorial. If you’re curious about how NTFS handles file recovery or need insights into its inner workings, you’re in the right place. We provide expert solutions and explanations to help you grasp the NTFS file recovery algorithm effortlessly. Learn critical steps and gain insights into ensuring the safety of your valuable data stored within NTFS file systems.
NTFS file system
Compared FAT, the NTFS is a nearly perfect file system to recover lost data. After all, it was designed to be robust, and has built-in data recovery and corruption protection mechanisms. Clearly, its designers thought of many things that never occurred to the developers of the earlier file systems. As a result, NTFS permits a data recovery tool to identify and recover all sectors that were occupied by a given file. The only (slight) drawback of NTFS is its tendency to lose the names of deleted files, which, to be fair, only happens under certain circumstances.
Parameter | FAT | NTFS |
---|---|---|
Full Name | File Allocation Table | New Technology File System |
Year of Development | 1977 | 1993 |
Maximum File Size | 4 GB | 16 TB (or more depending on the version) |
Maximum Volume Size | 8 TB | 256 TB |
Journal Support | No | Yes |
Performance | High on small volumes | Better on large volumes and with large files |
Security | No built-in protection | Supports encryption and access control |
Compatibility | Broad, supported by almost all devices | Less compatible than FAT, but supported by Windows and some other OS |
Usage | Small storage devices, USB drives | Hard drives, system partitions, working with large files |
How NTFS Deleted Files
Let’s have a look at what happens when Windows deletes a file from an NTFS volume (as opposed to recovering information from damaged volumes with corrupted file systems). Recovering a file deleted from an NTFS volume is simpler than undeleting one in most other file systems. For example, if you were using FAT, the chain of file allocation pointers identifying clusters occupied by the file would be lost when the file was deleted. This does not happen in NTFS.
When deleting a file from HDD or USB disk, memory card CompactFlash, MicroSd, its name is excluded from the parent directory index; the corresponding MFT record as well as all the clusters occupied by that file are released. The index is rearranged, at which time information about the name of the file may be lost. As a result, the deleted file will no longer appear in its containing directory.
However, this small drawback is compensated by that fact that MFT stores all records in a single table. As a result, it becomes much easier to locate available records. Each record contains an attribute containing the base address of the parent catalog. This in turn means that, after locating an empty record, we can determine the record’s full path.
In order to recover files deleted from an NTFS volume, one must scan the MFT looking for empty (available) records. If an empty record is located, one may be able to determine the file name, which is stored in one of the attributes. As you remember, determining file names is not always possible. However, unlike in the case of FAT volumes, all pointers to clusters occupied by that file will still exist. This means we can recover files of any size, even if severely fragmented – of course if its clusters have not been claimed by other files.
As you may remember, some very small files can be stored in the MFT as attributes. These files are called resident files. If a resident file occupied a single MFT record, it can be recovered until the MFT record is re-allocated.
NTFS has a special algorithm for allocating MFT records. When allocating an MFT record, Windows will attempt to make use of the first available record based on its number. As a result, records with lower MFT record numbers are allocated more often than those with higher record numbers.
NTFS Transaction Log
Transaction log is an essential feature of NTFS. NTFS transaction log records information about write operations into a special file. NTFS transaction log is not always active; however, it contains information about file delete and last editing time.
NTFS is a self-repairing file system. Transaction log is one of the tools allowing the system to rollback changes that led to file system corruption. More often than not, the file system gets damaged during a write operation, for example, if there is a power outage or a system failure at the time the system writes something onto the disk. If the system detects an improper shutdown, or if the “dirty” flag is set during the reboot, Windows analyzes NTFS transaction log. The transaction log contains information about upcoming updates to meta data, and register these updates once they are successfully committed.
So what happens if there is a failure during a write operation? In this case, Windows analyzes the transaction log and rolls back the state of the file system to prior condition. NTFS transaction log does not contain non-resident user data. However, it does contain all resident attributes in order to enable the rollback. As a result, the transaction log cannot be used to recover larger files.
Essentially, the use of the transaction log to recover files it limited. The log makes much more sense when recovering the integrity of the file system by rolling back non-committed changes, which causes the loss of last written data. As a result, Hetman Partition Recovery does not use NTFS transaction log.
Yes, there are risks associated with NTFS file recovery. These include:
To avoid these risks, it is important to use a reliable and trusted NTFS file recovery tool. It is also important to make sure that the recovery tool is compatible with the version of NTFS being used on the system. Additionally, it is important to back up all data prior to attempting any type of file recovery.