FreeDOS MOVE: Rename, Relocate, and Verify Without Losing the Source

FreeDOS MOVE is an external utility for relocating files or directories. It is related to REN, COPY, and XCOPY, but those commands have different contracts. A same-volume directory rename can update a directory entry without copying the tree, while moving data to another volume necessarily crosses a filesystem boundary. The FreeDOS help describes valid command forms and options, but does not promise transactionality, rollback, or identical behavior across every filesystem driver and utility build.

That distinction matters when the source contains irreplaceable data. “Move” describes the requested outcome, not a guarantee that every intermediate state is invisible or recoverable. Plan cross-volume changes as a staged migration: preserve the source, copy and verify a destination, and remove the source only after an independent check. If an error occurs, stop and inspect both locations rather than rerunning blindly.

Parse the destination before pressing Enter

The documented syntax accepts one or more source names and a destination:

MOVE [/Y | /-Y] [/V] SOURCE1[,SOURCE2[,...]] DESTINATION

A destination may be a directory or a new directory name. FreeDOS Help gives examples where a file is moved into a destination directory and where a directory is moved to a new name. It also explains that renaming a directory on the same drive can produce the same result as REN; the REN syntax is narrower and operates within the same drive and directory context.

Use fully qualified paths when the operation crosses drives. Remember that D:ARCHIVE is relative to the current directory remembered for drive D, while D:\ARCHIVE is rooted at the drive. In scripts, a drive-relative target can therefore resolve differently depending on commands that ran earlier. Before executing a batch relocation, print the source and destination, check the current directory on every involved drive, and confirm that the target volume is present and writable.

When multiple sources are listed, be explicit about whether the destination is intended to be a directory. Avoid relying on ambiguous trailing separators or shell wildcard expansion without a test run. A pattern such as *.* can match more than the operator expected under DOS filename rules; first list the matching files with DIR, then use a disposable staging copy to validate the exact set.

Same-volume rename and cross-volume transfer are different risks

Within one filesystem, renaming a directory usually changes namespace metadata while leaving file contents in place. That is operationally different from moving the same directory tree to another drive. On a cross-volume move, a utility must transfer file contents somehow; do not infer that the action is an atomic directory-entry rename or that an interruption leaves both sides unchanged. The available FreeDOS command reference does not define a failure-atomicity guarantee.

Consider what can fail between the first and last file: destination space may run out, a floppy may be removed, a USB driver may reset, a file may be locked, the source may have a read error, or the system may lose power. The result may be a subset of files at the destination and a subset still at the source. This is why an operator should treat the source as authoritative until the copy has been verified and the application has successfully used the destination.

Directory operations also interact with existing destination names. If a file of the same name exists, /Y suppresses the overwrite prompt and /-Y requests confirmation. /V verifies files as they are written according to the help reference. These flags do not establish a merge policy for every collision scenario; test the exact utility version and representative tree before a production move. Do not use /Y as a generic repair for a failed move.

Use a staged cross-volume migration

For valuable directories, separate copy and deletion into two controlled phases. First copy into a new staging directory on the destination volume. The command can be XCOPY when the task requires recursive tree copying and its attribute/empty-directory switches are understood. Then compare expected path names, byte lengths, and checksums for critical files. Open representative databases, documents, and executables from the destination. Only after the verification record passes should an operator retire the source.

An example of a staged file transfer might look like this:

MD D:\STAGE\PROJECT
COPY /B C:\PROJECT\BINARY.DAT D:\STAGE\PROJECT\BINARY.DAT
COPY /A C:\PROJECT\README.TXT D:\STAGE\PROJECT\README.TXT

The example deliberately separates binary and text modes. For a directory tree, replace individual COPY commands with an appropriate recursive tool and test how it handles hidden, system, read-only, zero-length, and empty-directory entries. A successful command message is only one item of evidence. Do not delete C:\PROJECT until the destination has been independently checked.

When an actual MOVE operation is appropriate, try it first on a disposable directory containing representative files and collisions. Record whether the destination directory is created, whether an existing directory is merged or rejected, how prompts appear, and what remains after deliberately simulating a safe interruption in a test image. Do not simulate interruption on production media.

Verification and recovery after partial completion

If MOVE reports an error, capture the complete message and return code before entering another command. Check the destination for files that arrived, compare them with the source, and inspect whether any source names disappeared. Avoid commands that automatically delete or replace files until the state is mapped. A second MOVE can behave differently because the first attempt may have changed the set of inputs or created an empty destination directory.

Use /V when its additional write verification is useful, but add independent checks for high-value data. A verifier may compare data as the utility writes it; a checksum created after the operation helps detect later changes but does not tell whether the original source was already wrong. Maintain a manifest generated before migration when provenance matters. Check the volume label and free space rather than trusting drive letters alone, especially when removable drives and DOS redirectors are involved.

For a same-volume rename, record the pre-operation and post-operation directory path, count the entries, and open representative files. For a cross-volume transfer, record both source and destination volume identities, the file-level comparison result, any error output, and the point at which the source was retired. If the source is a directory containing nested content, use a tool whose recursive semantics are documented rather than assuming MOVE’s behavior matches a modern shell’s implementation.

Batch automation needs a deletion barrier

Classic DOS batch files do not provide a transaction manager or structured exception handling. A robust script should validate parameters, confirm that the source exists, confirm the destination volume, create a unique staging path, check the utility’s documented exit status immediately, and stop on any failure. Keep the source untouched until a separate verification step succeeds. Use reverse-ordered IF ERRORLEVEL tests when the utility defines increasing result codes, because FreeCOM treats IF ERRORLEVEL n as a test for n or greater.

Do not chain a relocation and source cleanup on one line or in a script that ignores the return code. Do not allow a failure branch to fall through into DEL, DELTREE, or another cleanup command. If users choose the destination interactively, validate the exact volume and path before continuing. A backup is useful only if it is a separate copy that has been checked and can be restored.

The acceptance criterion is not that MOVE returned to the prompt. It is that the intended objects exist at the intended destination, their contents and required metadata meet the task’s requirements, no unaccounted source or destination files remain, and the recovery path is documented. For high-impact relocations, preserve a disk image or a separate backup before the operation.

Related:

Sources: