FreeDOS COPY: Text and Binary Modes, Concatenation, and Safe Overwrites
Use FreeDOS COPY safely by controlling text and binary mode, concatenation, overwrite policy, COPYCMD defaults, devices, and post-write verification.
FreeDOS COPY is a command implemented by the command interpreter, not a standalone executable that must be found on PATH. It is useful for moving ordinary files, sending a text stream to a device, and concatenating compatible inputs. Its deceptively small interface also has consequential behavior: /A can translate text and stop at an end-of-file marker, /B preserves bytes, and COPYCMD can change overwrite prompting without changing the visible command line.
Treat COPY as a byte-moving operation with explicit policy, not as a backup system. It does not create a transaction, promise rollback after a full disk or I/O error, preserve every filesystem attribute, or prove that the destination is an independently verified backup. Before copying important data, record the interpreter version, effective environment, exact source pattern, destination, overwrite policy, and verification method.
Resolve the two command forms first
The ordinary form copies one or more source files to a destination. A single source may target a file or a directory; when the destination names a directory, the source filename is retained. Multiple source files require a directory target. If one source is given without a target, the current directory is the default, which can be surprising in a batch file whose working directory changed earlier.
The second form concatenates inputs into one output file. FreeDOS help documents both a plus-separated input list and wildcard expansion for multiple source files. These are not equivalent to copying a tree: COPY does not recurse into subdirectories and its help explicitly directs users to XCOPY for directories and zero-length files. An empty file can be meaningful, so do not infer that a successful-looking bulk command included it.
For operational scripts, make the destination explicit and use a controlled working directory. Avoid relying on a drive-relative operand such as D:OUT.DAT when you mean a root-relative path; D:OUT.DAT follows that drive’s current directory. A fully qualified destination such as D:\STAGE\OUT.DAT communicates intent more clearly. Also confirm that the destination is not the same file as a source through a different spelling, mapped drive, or directory alias.
/A and /B change the data contract
In binary mode, bytes are copied without text conversion. That is the correct choice for executables, archives, disk images, compressed data, databases, and any file whose exact byte sequence matters. FreeDOS help describes binary mode as making no changes to the file contents.
ASCII mode has text-oriented behavior. The documented COPY implementation translates DOS carriage-return/line-feed pairs to a single newline representation when reading and translates the newline back to the DOS pair when writing. It also treats Ctrl-Z (1Ah) as an end-of-file marker on input, ignoring subsequent bytes, and may append that marker when writing an ASCII output. Those rules can corrupt binary data, truncate text files that legitimately contain Ctrl-Z, or change hashes even when the resulting text looks the same in an editor.
The mode switches are positional. FreeDOS help says /A or /B applies to the file immediately before it and following files until another mode switch changes the setting. When concatenating, place switches deliberately at the boundaries of the input and output. Do not assume that a switch placed at the beginning describes every later operand independently. Test the installed FreeCOM version with disposable files containing CRLF, a Ctrl-Z byte, and bytes after that marker before depending on conversion behavior.
For example, the following is a text concatenation only if all three inputs are truly text and Ctrl-Z handling is acceptable:
COPY /A C:\REPORTS\PART1.TXT + /A C:\REPORTS\PART2.TXT /A D:\STAGE\MERGED.TXTFor exact binary concatenation, specify binary mode and confirm that the resulting format is meant to be a raw byte concatenation. Combining arbitrary executable or archive files does not create a valid archive or executable merely because COPY accepted the command.
Overwrite prompts are part of the environment
/Y suppresses the confirmation prompt before an existing destination file is overwritten; /-Y requests confirmation. FreeDOS COPY also consults COPYCMD before processing its command line. The documented SET COPYCMD=/Y example makes overwrite acceptance the default for both COPY and XCOPY. That is shared ambient state: a command that appears interactive in one shell may be silent in another.
Before a run that can replace data, inspect the current value with SET COPYCMD. In a controlled batch job, set or clear the variable intentionally and state the desired option on the command itself. Use /Y only when the destination is disposable or a reviewed replacement is explicitly intended. Use /-Y when a person should confirm conflicts, but do not treat a prompt as a complete safety mechanism: the operator still needs to know which file will be overwritten.
Redirection creates another overwrite boundary. A command such as COPY SOURCE.BIN DEST.BIN is not the same operation as redirecting console output with >. If you use COPY CON: FILE.TXT, the source is the console device and the keystrokes form a stream; Ctrl-Z conventionally signals completion for this DOS workflow. Device names have DOS-specific behavior, so test them on the actual console or redirector and never assume that a device source behaves like a normal disk file.
Verify writes without confusing verification with backup
/V asks COPY to verify that new files were written correctly. The DOS VERIFY flag is related but separate state; inspect the exact command documentation rather than assuming that one switch toggles the other. Verification can detect some write errors, but it does not prove that the source was the intended version, that metadata was preserved, or that a later restore will work.
A safer migration workflow is to copy into a new staging directory, compare the expected file list, inspect sizes, and use an independent checksum utility on both source and destination for important binaries. Retain the original until the destination has been opened by the intended application or restored in a test environment. A displayed “1 file(s) copied” message is not an integrity audit.
When copying many files, split the task into bounded groups so an error is attributable. Capture console output to a log only after checking that the shell’s redirection behavior is suitable; a destination log can itself overwrite an existing file. After an I/O error, stop and inspect both sides. Do not blindly rerun with /Y, because some files may already have been copied and a rerun can replace a good destination with a partial or stale source.
A reversible test plan for scripts
Build a disposable fixture containing a zero-length file, a small text file with DOS line endings, a text file with a Ctrl-Z byte, a binary file with all byte values, and a destination file with a sentinel value. Run one command form at a time. Record COPYCMD, test both overwrite choices, check output names and lengths, and compare hashes for binary mode. Then repeat under the same boot profile and shell used in production.
Do not include recursive directory expectations in the test oracle; COPY is not a tree copier. Do not assume wildcard ordering unless the installed command documents it. If a program depends on concatenation order, use explicit file operands and inspect the output boundaries. If a format has its own archive, database, or image utility, use that format-aware tool instead of raw concatenation.
An acceptance record should identify the source set, destination volume, FreeCOM version, active COPYCMD, selected /A or /B mode, /V choice, overwrite decision, return output, and independent verification result. That evidence distinguishes “the command ran” from “the intended bytes reached the intended place.”
Related:
- FreeDOS XCOPY: Tree Copies, Switch Semantics, and Verification
- FreeDOS VERIFY: What Write Verification Checks and What It Cannot
Sources: