DELTREE on FreeDOS: Recursive Deletion, Preview, and Exit Codes

FreeDOS DELTREE removes a directory and the files and subdirectories beneath it. That is useful for controlled cleanup, but the tool’s strength is also its risk: it can delete read-only, hidden, and system files, and a single wildcard can select more than the operator intended. The command provides a /X test mode that lists what it could delete without deleting anything. A safe workflow uses that preview, an exact absolute path, a backup outside the tree, and a second human review before the real command.

Understand the target model

The FreeDOS DELTREE syntax accepts one or more filespecs and optional switches. A filespec may name a file, directory, or a DR-DOS-style file list. Wildcards are accepted and can target matching files and directories. When a directory is selected, its contents and descendant directories are in scope. This is recursive removal, not the same operation as removing a single empty directory with RMDIR.

The command does not use file attributes as a safety boundary. The FreeDOS help explicitly says files are deleted regardless of Read-only, Hidden, or System flags. Setting R on a directory therefore does not protect its contents from DELTREE. Similarly, moving a folder to a different parent is not a recovery plan; a delete can remove a large tree quickly, and FAT does not have a general recycle-bin transaction.

Before acting, identify the current drive and directory with CD, then use a full target path. Do not rely on the shell prompt as proof of current working directory: batch scripts, secondary shells, and drive-relative paths can make that assumption false. Avoid a bare *.* and avoid a target rooted at C:\ or another drive root. If the path is not obvious to a second operator reading the command, do not execute it.

Use `/X` as a rehearsal

DELTREE’s /X switch is documented as a testing mode: it displays the files and directories that could be deleted but does not delete them. It is an unusually useful feature, but it is not a transaction or a lock. Files can change between preview and execution, and the preview does not guarantee that every later filesystem operation will succeed.

Start with help and a preview of one exact directory:

C:\>DELTREE /?
C:\>DELTREE /X C:\BUILD\TEMP

Read every displayed path. Check that the first component is the intended target and that siblings, parent directories, and unrelated drive letters are absent. If the preview is unexpectedly empty, do not assume the directory is already clean; the path may be wrong, a wildcard may not match, or the installed version may parse syntax differently. Check the command’s output and ERRORLEVEL instead.

If and only if the preview is correct, rerun the same explicit target without /X and without /Y:

DELTREE C:\BUILD\TEMP

The normal mode prompts before removing items specified on the command line; answer only after reviewing the displayed target. /Y suppresses prompts and should not be used in manual or recovery-sensitive work. FreeDOS documentation describes build variants with different safeguards, so inspect the exact DELTREE executable and do not assume the default root-safety behavior applies to every binary named DELTREE.COM.

Build variants are operationally significant

The FreeDOS documentation describes a default build with a root-safety check, a DELTREE2.COM defanged build that ignores /Y and always asks, and a dangerous build named DELTREE!.COM without the root-safety check. The existence of multiple variants means a script’s safety cannot be inferred from the command name alone. Check the executable resolved through PATH, record its version/help output, and test it in a disposable directory.

If an automated cleanup must run unattended, use a deliberately selected and reviewed executable, an exact non-root target, and a separate backup policy. Do not rely on a prompt appearing: redirection, a different build, an unexpected executable earlier in PATH, or an incompatible shell can change the interaction. Safer automation may use a purpose-built cleanup routine with an explicit allowlist and logs, but it too must be tested on a copied tree.

File lists and wildcards

DELTREE supports @FILELIST.TXT to identify a list file. The documentation describes a DR-DOS-style file list with paths and optional semicolon comments. This is convenient for reviewed batches, but the list becomes another input that must be protected from stale or accidental edits. Confirm the file’s exact contents, line endings, quoting rules, and location before use. A literal filename beginning with @ should be quoted according to the documented example to prevent it being parsed as a list.

Wildcards deserve extra caution because they are selection patterns, not a preview guarantee. Patterns can include files and directories; a wildcard in a parent component can expand to multiple trees. Prefer one named directory at a time. If you need a list, capture /X output in a log on a different volume and review it. Do not pipe a generated target list straight into destructive execution without human review.

Preserve evidence and recovery options

If the target might contain unique data, copy or image it before running DELTREE. Store the backup on a different physical device or a separate immutable snapshot; backing up inside the tree being removed defeats the purpose. Verify the copy with a byte comparison or trusted checksums. For forensic or accidental-deletion recovery, stop writing to the volume immediately. Further writes can reuse clusters holding deleted file contents.

DELTREE is not a secure-erasure tool. Deleting directory entries and freeing FAT clusters changes filesystem metadata but does not necessarily overwrite file data sectors. Conversely, a filesystem recovery utility may fail if metadata has been overwritten or the storage device has additional behavior. Treat successful deletion as namespace cleanup, not proof that sectors have been sanitized or data is unrecoverable.

The /V option reports totals when deletion completes. Its reported file sizes do not account for cluster allocation overhead, so the amount of disk space freed can differ from the printed byte total. It is a summary, not an audit log of every original file. If you need a defensible record, save a pre-delete inventory, the preview output, the command line, the utility version, the final output, and the post-delete directory listing.

Exit codes and batch control

FreeDOS documents exit codes for success, deletion or file-list failure, user abort, syntax/buffer errors, insufficient memory, DOS-version requirements, and path-resolution issues. In DOS batch language, IF ERRORLEVEL n is a greater-than-or-equal test. For example, checking for nonzero with IF ERRORLEVEL 1 catches all positive errors, but if you need to distinguish codes, test from highest to lowest.

DELTREE /X C:\BUILD\TEMP
IF ERRORLEVEL 1 GOTO PREVIEW_FAILED

This only guards the preview step; it does not authorize deletion. A human or separate policy check must still review the displayed target set. In unattended cleanup, write an explicit log and stop on any unexpected return code. Do not treat exit code zero as evidence that the correct directory was selected; it means the utility considered the requested operation successful.

Common failure modes

“File not found” or an empty preview often comes from a drive/path mismatch. DOS drive letters have per-drive current directories, so C:TMP is not the same as C:\TMP; an absolute path avoids that ambiguity. A “cannot delete” result can reflect an open file, a driver error, a malformed path, insufficient memory, or a FAT problem. Do not respond by adding /Y or stripping all attributes. Close the owning program, preserve the tree, and identify the actual error.

If deletion is part of a software build, prefer a build directory dedicated to generated artifacts and verify its absolute path at script start. Avoid setting the current directory to a user-data volume and then using relative cleanup patterns. Keep source files, output files, and temporary build trees separate so a mistake in one path cannot erase both inputs and backups.

Acceptance checklist

Before the real run, confirm: the intended executable path and version; a specific absolute target that is not a drive root; a verified backup if any data matters; a /X preview matching the intended set; no unreviewed wildcard or stale list; and a deliberate decision not to use /Y. Afterward, record the exit code, inspect the parent directory, and verify that unrelated sibling files remain. For automated processes, repeat this test using the same shell, DOS kernel, filesystem, and DELTREE binary expected in production.

Related:

Sources: