FreeDOS REPLACE: Controlled File Updates and Safe Deployment

FreeDOS REPLACE copies matching source files into a destination directory, replacing destination files with the same names. Its /A, /U, /S, /N, /P, /H, and /R options describe materially different update policies. Treat the utility as a controlled file deployment tool, not a transaction manager: the command reference does not promise an all-or-nothing operation, content-hash comparison, automatic backup, or rollback.

The basic shape is:

REPLACE [source-filespec] [destination-directory] [options]

For example, a preview of newer source files can be requested with:

REPLACE C:\STAGE\BIN\*.* C:\APP\BIN /N /U

The FreeDOS documentation defines /N as preview mode that does not add or replace files, and /U as replacing only destination files older than their source. This pairing is useful before a controlled refresh, but preview output is not an integrity proof. It says nothing about whether the source package is authentic, whether a file is the intended build, or whether the destination contains local modifications that should be preserved.

Define the desired update set first

Use an isolated staging directory for verified package files. Before REPLACE runs, enumerate the source set and the destination set, confirm the destination path, and record a backup or copy of the current application directory. In DOS, drive-relative paths such as C:BIN and rooted paths such as C:\BIN have different resolution rules. Prefer explicit absolute paths for both arguments and confirm the current drive anyway.

/U is timestamp-based according to the help page: a destination is updated only when it is older than the source. It does not compare file bytes or semantic versions. FAT timestamps have limited precision and no embedded timezone, so a timestamp-only rule can fail to distinguish content accurately across copied media or clock changes. If exact bytes matter, separately compare files or verify package checksums before replacing anything.

/A adds new files to the destination directory. The FreeDOS reference says /A cannot be used with /S or /U. Do not combine switches based on behavior from a different implementation. If the goal is to add missing names and replace existing content, test the precise FreeDOS command against a disposable tree and inspect the resulting inventory.

/S searches destination subdirectories for files to replace. That expands the write scope beyond the destination’s top level. Use it only when recursive deployment is intentional; enumerate the directory tree first and make a restore copy outside it. The docs describe replacing files in destination subdirectories, but do not imply that REPLACE mirrors deletion or removes destination-only files. Avoid calling it a synchronization tool.

Treat each option as a policy

/N previews without adding or replacing files. Start here and save or photograph the output as a review record.
/P asks before replacing a file or adding a source file. Use it where a human can inspect each prompt and the correct media remains mounted.
/U updates only when the destination file is older than the source. It is a timestamp comparison, not a hash or version check.
/S extends replacement into destination subdirectories. It widens scope and should be tested on a copied tree.
/A adds new source files to the destination, but cannot be combined with /S or /U according to FreeDOS Help.
/H includes hidden and system files as well as unprotected files; include it only when those attributes are expected.
/R permits replacing read-only files. This is a permission override, not a safe way to discover why a file is protected.
/W waits for a disk to be inserted before it begins. It does not verify that the inserted disk is the correct release medium.

The option names are short and easy to misread. Record the intended policy in plain language before forming the command. “Copy any missing file” is not the same operation as “replace only older destination versions,” and recursion is not equivalent to a mirror. A familiar switch on a different DOS utility may have different semantics.

A cautious deployment sequence

DIR C:\STAGE\BIN
DIR C:\APP\BIN
REPLACE C:\STAGE\BIN\*.* C:\APP\BIN /N /U

Review the preview. Confirm the source package, destination application, and update list. If approved, run an interactive pass:

REPLACE C:\STAGE\BIN\*.* C:\APP\BIN /P /U

Do not assume the preview and execution are atomic with respect to filesystem changes. Keep the source read-only and do not modify either tree between the review and execution. If another process or operator can alter the target, stop and coordinate a maintenance window.

After execution, re-enumerate the destination. Compare expected filenames and relevant sizes or checksums using a trusted tool. Confirm that the application starts, opens its data, and reports the intended version. A REPLACE exit status is a command-level result, not proof that the application is healthy. Retain the pre-update copy until functional validation completes.

Interpret failure results conservatively

FreeDOS Help lists return values for no error, missing source file, missing path, access denied, invalid syntax, read fault, write fault, and insufficient disk space. The reference also marks some codes as not implemented in the described utility. Do not base automation on an error code unless the installed version documents and actually returns it. In a batch file, test error levels from most specific/highest down because FreeCOM’s IF ERRORLEVEL n convention is “greater than or equal to n.”

If the update fails partway through, do not rerun recursively without understanding the partial state. Preserve the source and the current destination, inspect which files changed, check free disk space and media health, then either complete the same planned update or restore from the backup. A write fault may indicate a real destination problem; retrying can worsen a failing disk.

Common deployment mistakes

One mistake is staging from a working directory that contains editor backups, debug builds, or files from another release. REPLACE acts on the filespec supplied; it cannot determine which source files belong in production. Another mistake is using *.* without confirming how the target command treats extensionless names. Test the installed implementation with a small fixture when the file set includes unusual names.

It is also unsafe to combine /H and /R reflexively. Hidden/system and read-only attributes may protect files for a reason. Review each file’s role and preserve its current attributes in your backup. A recursive replacement can cross into subdirectories whose contents are owned by a different installer or user.

Finally, do not interpret /U as a semantic upgrade policy. If the system clock was wrong when files were copied, or the filesystem timestamp granularity collapses nearby build times, “older” may not correspond to “outdated.” A release manifest or checksum comparison is a stronger source of truth.

Acceptance checks

On a disposable tree, test at least one matching destination file, one newer destination file, one missing destination file, one read-only file, and one nested file. Confirm which switches include each file and what the preview prints. Then test a deliberate missing source and a destination without sufficient space only in a disposable environment. Record exact FreeDOS version and results before using the command in an unattended script.

REPLACE is most useful when the source and target sets are explicit, the replacement policy is simple, and rollback is external to the command. If a deployment requires atomic directory swaps, hash enforcement, deletion of stale files, or reliable recovery after power loss, use a platform and tool designed to provide those properties. REPLACE can participate in a careful DOS maintenance plan; it cannot supply guarantees that its reference does not document.

Related:

Sources: