Undeletion

Norton UNERASE was an important component in Norton Utilities version 1.0 in 1982.

Microsoft included a similar UNDELETE program in versions 5.0 to 6.22 of MS-DOS, but applied the Recycle Bin approach instead in later operating systems using FAT.

DR DOS 6.0 and higher support UNDELETE as well, but optionally offer additional protection utilizing the FAT snapshot utility DISKMAP and the resident DELWATCH deletion tracking component, which actively maintains deleted files' date and time stamps and keeps the contents of deleted files from being overwritten unless running out of disk space. DELWATCH also supports undeletion of remote files on file servers. Since Novell DOS 7 the kernel will store the first letter of deleted files in the directory entries in order to further assist undeletion tools in recovering the original name.

PTS-DOS offers the same feature, configurable by a SAVENAME CONFIG.SYS directive.

The FreeDOS version of UNDELETE was developed by Eric Auer and is licensed under the GPL.[11]

Graphical user environments often take a different approach to undeletion, instead using a "holding area" for files to be deleted. Undesired files are moved to this holding area, and all of the files in the holding area are deleted periodically or when a user requests it. This approach is used by the Trash can in Macintosh operating systems and by the recycle bin in Microsoft Windows. This is a natural continuation of the approach taken by earlier systems, such as the limbo group used by LocoScript.[12] This approach is not subject to the risk that other files being written to the filesystem will disrupt a deleted file very quickly; permanent deletion will happen on a predictable schedule or with manual intervention only.

Another approach is offered by programs such as Norton GoBack (formerly Roxio GoBack): a portion of the hard disk space is set aside for file modification operations to be recorded in such a way that they may later be undone. This process is usually much safer in aiding recovery of deleted files than the undeletion operation as described below.

Similarly, file systems that support "snapshots" (like ZFS or btrfs), can be used to make snapshots of the whole file system at regular intervals (e.g. every hour), thus allowing recovery of files from an earlier snapshot.

When a file is "deleted" using a FAT file system, the directory entry remains almost unchanged except for the first character of the file name, preserving most of the "deleted" file's name, along with its time stamp, file length and — most importantly — its physical location on the disk. The list of disk clusters occupied by the file will, however, be erased from the File Allocation Table, marking those sectors available for use by other files created or modified thereafter. In case of FAT32, it is additionally erased field responsible for upper 16 bits of file start cluster value.

When undeletion operation is attempted, the following conditions must be met for a successful recovery of the file:

• The entry of the deleted file must still exist in the directory, meaning that it must not yet be overwritten by a new file (or folder) that has been created in the same directory. Whether this is the case can fairly easily be detected by checking whether the remaining name of the file to be undeleted is still present in the directory.
• The clusters formerly used by the deleted file must not be overwritten yet by other files. This can fairly well be verified by checking that the clusters are not marked as used in the File Allocation Table. However, if, in the meantime, a new file had been written to the disk, using those sectors, and then deleted again, freeing those sectors again, this cannot be detected automatically by the undeletion program. In this case an undeletion operation, even if appearing successful, might fail because the recovered file contains different data.
• For FAT32 devices, the lower 16 bits of the physical address is normally retained in the directory entry, but the high bits of the address are zeroed down. Many recovery programs ignore this fact and fail to recover data correctly.

Chances of recovering deleted files is often higher on FAT12 and FAT16 as compared to FAT32 volumes due to the typically larger cluster sizes used by the former systems and due to loss of upper 16 bits of logical cluster address for FAT32.

If the undeletion program cannot detect clear signs of the above requirements not being met, it will restore the directory entry as being in use and mark all consecutive clusters, beginning with the one as recorded in the old directory entry, as used in the File Allocation Table. It is then up to the user to open the recovered file and to verify that it contains the complete data of the formerly deleted file.

Recovery of fragmented files (after the first fragment) is therefore not normally possible by automatic processes, only by manual examination of each (unused) block of the disk. This requires detailed knowledge of the file system, as well as the binary format of the file type being recovered, and is therefore only done by recovery specialists or forensics professionals.

NTFS stores file information as a set of fixed-size records (typically, 1KB) within the so-called Master File Table (MFT). File name and file allocation information are encapsulated into these records, providing complete information about each specific file. When the system deletes a file, the entry in the Master File Table is released to be either unlinked or reused, but it still remains on disk. Until the MFT entry is reused or overwritten, the file can be easily recovered: data recovery software can find the "lost" MFT entry and derive full information about the lost file from it.

Note however, when the SSD TRIM function is enabled, file content may be destroyed shortly after deletion to reuse SSD memory cells. This makes file content recovery impossible (only name, date and file size information will remain on the disk).