This article needs additional citations for verification. (February 2017) (Learn how and when to remove this template message)
Undeletion is a feature for restoring computer files which have been removed from a file system by file deletion. Deleted data can be recovered on many file systems, but not all file systems provide an undeletion feature. Recovering data without an undeletion facility is usually called data recovery, rather than undeletion. Although undeletion can help prevent users from accidentally losing data, it can also pose a computer security risk, since users may not be aware that deleted files remain accessible.
Not all file systems or operating systems support undeletion. Undeletion is possible on all FAT file systems, with undeletion utilities provided since MS-DOS 5.0 and DR DOS 6.0 in 1991. It is not supported by most modern UNIX file systems, though AdvFS is a notable exception. The ext2 file system has an add-on program called e2undel which allows file undeletion. The similar ext3 file system does not officially support undeletion, but utilities like ext4magic, extundelete, PhotoRec and ext3grep was written to automate the undeletion on ext3 volumes. Undelete was proposed in ext4, but is yet to be implemented. However, a trash bin feature was posted as a patch on December 4, 2006. The Trash bin feature uses undelete attributes in ext2/3/4 and Reiser file systems.
Norton UNERASE was an important component in Norton Utilities version 1.0 in 1982.
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.
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. 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.
Undeletion is not fail-safe. In general, the sooner undeletion is attempted, the more likely it will be successful. This is because the more a system is used, the more data is written to the drive and potentially allocated to that deleted space. Fragmentation of the deleted file may also reduce the probability of recovery, depending on the type of file system (see below). A fragmented file is scattered across different parts of the disk, instead of being in a contiguous area.
The workings of undeletion depend on the file system on which the deleted file was stored. Some file systems, such as HFS, cannot provide an undeletion feature because no information about the deleted file is retained (except by additional software, which is not usually present). Some file systems, however, do not erase all traces of a deleted file, including FAT file systems:
FAT file systems
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 file systems
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).
Data erasure is term that refers to software-based methods of preventing file undeletion.
- "When Not to Use MS-DOS 5.0 CHKDSK and UNDELETE Commands". Support.microsoft.com. 2006-11-16. Archived from the original on 2012-02-02. Retrieved 2012-01-09. Cite uses deprecated parameter
- "Using a Common UNDELETE.INI File with Undelete". Support.microsoft.com. 1999-11-16. Archived from the original on 2009-08-26. Retrieved 2012-01-09. Cite uses deprecated parameter
- Carlo Wood (2008-02-07). "HOWTO recover deleted files on an ext3 file system". Xs4all.nl. Archived from the original on 2010-09-19. Retrieved 2012-01-09. Cite uses deprecated parameter
- New ext4 features Archived December 18, 2008, at the Wayback Machine
- "Secure Deletion and Trash-Bin Support for Ext4". Article.gmane.org. Archived from the original on 2008-07-09. Retrieved 2012-01-09. Cite uses deprecated parameter
- "Gmane Loom". Thread.gmane.org. Archived from the original on 2016-01-11. Retrieved 2012-01-09. Cite uses deprecated parameter
- "Langford in PCW TODAY column #6". Ansible.co.uk. Archived from the original on 2012-02-14. Retrieved 2012-01-09. Cite uses deprecated parameter