Skip to content
FreeDOSDeep Dive Published Updated 6 min readViews unavailable

FreeDOS UNDELETE: Non-Destructive FAT Recovery and Evidence Handling

Use FreeDOS UNDELETE in list/export-first recovery workflows, understand cluster-chain limits, and avoid overwriting the only copy of deleted data.

FreeDOS UNDELETE attempts to recover deleted files. The word “attempts” is essential: recovery depends on what the filesystem has changed since deletion, whether the original data clusters remain intact, and whether the directory and allocation metadata still contain enough information to reconstruct a file. UNDELETE is not a substitute for a verified backup, a forensic imaging workflow, or a general filesystem repair utility.

The safest starting point is observation. FreeDOS Help documents /LIST as listing recoverable files without prompting or taking action. It also documents /E as exporting recovered files to an external disk without modifying the source disk. Use those modes before an in-place recovery, and never save recovered output to the same volume from which you are trying to recover data.

UNDELETE C:\DATA /LIST
UNDELETE C:\DATA /E D:\RECOVERED

Confirm the syntax on the installed UNDELETE binary before using it. In the documented form, the source directory is the path being examined and the export target is another drive. If the evidence matters, the stronger first step is to stop writes to the original medium, make a sector-level image using a trusted imaging process, calculate and record a checksum, and conduct experiments on a copy.

Why recovery becomes less likely over time

On FAT filesystems, deleting a file changes directory and allocation metadata; it does not guarantee that every content sector is immediately overwritten. However, clusters released by deletion can be reused by later writes. Once another file allocates those clusters, the original file can be partly or wholly overwritten. Directory entries may also be reused or lose information that a recovery utility needs to identify the original name, size, or cluster chain.

This explains why the best operational action after accidental deletion is to stop unnecessary activity. Do not install a recovery package onto the affected disk, create the export folder there, run a defragmenter, or continue using the system normally. Even a small write can allocate clusters that had contained deleted content. Boot from separate media if feasible, mount the source as read-only where the platform supports it, and direct every log and output file elsewhere.

Recovery confidence is file-specific. A short, contiguous file whose first cluster remains untouched may be recoverable even when a larger fragmented file is not. A recovered filename is not proof of complete contents; inspect the file’s internal structure and compare it with a known-good copy or application-level checksum.

Use the documented safe modes first

/LIST is the non-action inventory step. Save its output on a separate medium if a record is needed. /E exports recovered data and explicitly leaves the source disk unmodified according to the Help page. The destination must be on a different drive; the utility reads recovery data from the drive where it is invoked. Verify which drive letters refer to which physical or virtual devices before running the command. On DOS, a drive letter alone does not identify a physical device safely after boot-menu changes or removable-media swaps.

Avoid /ALL during the first pass. The reference says it automatically undeletes all recoverable files without prompting. That broad behavior can create many outputs and can make it harder to review ambiguous candidates individually. Begin with listing, identify likely files, export to separate media, then inspect content before deciding whether any restored copy should re-enter an application data set.

FreeDOS UNDELETE also documents advanced actions such as DIRSAVE, FOLLOW, EXTRACT, and SYSSAVE. These operate at a lower level and require cluster or sector interpretation. FOLLOW takes a starting cluster and saves a byte stream; its output may include unrelated data, fragments, or stale bytes. A directory listing from DIRSAVE can help locate deleted entries, but interpreting it is an expert task. Do not use advanced actions as a routine one-command recovery recipe.

The same Help page includes a warning that writing saved system metadata back to a damaged disk is for experts and very desperate situations because doing it incorrectly can make matters worse. This article does not recommend direct restoration with DEBUG or raw sector writes. Preserve the original, use a cloned image, and consult a qualified recovery specialist when filesystem metadata reconstruction is required.

Build a recoverable workflow

  1. Stop writes to the affected volume and document the machine, media, time, and incident.
  2. Identify the physical device behind the DOS drive letter without making changes.
  3. Image the medium to separate storage and record a checksum of the image.
  4. Run UNDELETE /LIST against a working copy, or use /E to export elsewhere if imaging is unavailable and the risk is accepted.
  5. Save logs and recovered candidates to another device with enough free space.
  6. Validate each candidate by size, file signature, application parser, or known hash; do not trust its recovered name alone.
  7. Preserve both the original image and recovery logs before returning any files to service.

The order matters. Creating an output directory on the source first can consume newly freed clusters. Running a “repair” utility can rewrite FAT copies or directory entries and reduce later recovery options. If a recovery attempt has already failed, stop and capture the current state before trying a different tool.

Interpreting recovered output

A file can be syntactically present but semantically incomplete. For a text configuration, inspect the expected ending and line count. For an archive, run its own integrity test on a copy. For an executable, verify its hash or signature if a trusted reference exists; do not execute an unknown recovered binary. For database or application files, use the application’s consistency checker on a duplicate, never on the sole recovered copy.

If two candidates have the same name, preserve both with distinct evidence names. Record the source path, tool action, destination, and time. Avoid overwriting the first candidate with a second recovery attempt; two partial candidates may contain different intact extents that a specialist can compare.

UNDELETE does not provide a guarantee that recovered content is authentic, complete, or safe. A successful completion means the program wrote an output according to its logic; it does not prove the intended file was reconstructed. A plausible filename and size are weak signals. Validation must use independent metadata or application-level structure.

Prevention and acceptance checks

For removable DOS systems, test backup restoration before an incident. Keep a second verified copy on independent media, periodically compare checksums, and ensure the backup is not mounted as the source during a destructive operation. A mirror of FAT structures can help in certain filesystem failures, but it is not a substitute for a file-level backup and can itself become stale.

Before accepting a recovery, confirm the command was run against the expected source and wrote only to a separate destination. Verify the exported file’s byte count, structure, and content against independent evidence. Keep a copy of the source image and logs. If the recovered bytes are valuable and the result is uncertain, stop DIY writes and get specialist review.

FreeDOS UNDELETE is valuable as a best-effort tool for FAT-era environments, especially when used in list-first and export-to-another-drive modes. Its limits are intrinsic to the changing allocation metadata and reusable disk clusters. The most effective recovery technique is still preventing writes and maintaining tested backups before deletion occurs.

Related:

Sources:

Comments