FreeDOS VERIFY: What Write Verification Checks and What It Cannot

The FreeDOS VERIFY command controls a DOS-level write-verification flag. Its syntax is simple, VERIFY ON or VERIFY OFF, but the name invites overconfidence. Turning it on does not calculate a cryptographic digest, compare an entire backup set, reserve disk space, repair a filesystem, or promise that a drive’s volatile write cache has reached nonvolatile media. It asks the DOS file-I/O path to verify writes according to the kernel’s supported behavior. Use it as one diagnostic or reliability measure, not as a substitute for independent copies and read-back comparison.

What VERIFY controls

In the FreeDOS command documentation, VERIFY is an internal COMMAND.COM command that sets the file-verification state; invoking it without an argument displays the current setting. FreeDOS also provides an external VERIFY utility, so if command lookup matters, inspect the active shell and executable search path. The command corresponds to DOS INT 21h function 2Eh, which sets or resets the verify flag; function 54h retrieves the state. These are global DOS settings rather than per-copy switches.

That global state has operational consequences. A program that writes a file does not have to call VERIFY itself for DOS to maintain the current setting. However, a program can use other APIs or device paths, and device drivers and redirects may implement different semantics. Therefore, VERIFY ON is not proof that every byte written by every application has been independently reread by a physical device. It is a DOS API contract whose effect is mediated by the running kernel and driver stack.

Set and inspect the state deliberately

Run VERIFY with no parameter to inspect the current state, then set the desired value explicitly:

C:\>VERIFY
Verify is OFF
C:\>VERIFY ON
C:\>VERIFY
Verify is ON

Exact display wording may be localized or differ by version; the important point is to inspect the state before changing it. If a temporary test began with VERIFY off, turn it off again afterward rather than silently leaving a performance-affecting global option enabled. This matters on slow floppy media and on old machines where every additional read can make a visible difference.

The setting may be stored in the DOS kernel and observed by child programs, but do not assume that every shell or DOS clone has identical command resolution or implementation details. A practical first check is VERIFY /? or HELP VERIFY, followed by a controlled test on a disposable image. If the shell says the command is unavailable, confirm whether an external utility is installed and whether its directory is on PATH.

How it fits into file writes

DOS normally buffers some file data to reduce device I/O. The operating system receives data through APIs such as handle-based writes, then the filesystem and device driver translate those operations into block requests. A verification mode can detect some write-path failures when the kernel or driver reads back data and compares it. This is useful for detecting certain media or transfer errors, especially when copying to removable media with known reliability problems.

But several distinct layers sit between an application and the recording medium: application buffers, DOS filesystem buffers, a block driver, a controller, and device-internal caching. A successful DOS-level check can only confirm what the implementation actually compared at its layer. It cannot independently attest that a modern controller has drained a volatile cache, that the data remains readable after power loss, or that the source file was correct before copying.

The exact amount of extra I/O and the exact cases verified depend on the kernel, device type, and operation. The classic API describes enabling verification of disk writes; it does not define a modern end-to-end durability protocol. Avoid quantitative promises such as “all writes are read twice” unless the specific installed kernel and driver source establish that behavior for the operation being tested.

VERIFY is not a checksum or backup

A checksum answers a different question. VERIFY ON concerns the DOS write path. A checksum compares a file’s computed digest to a trusted digest; FC /B compares two files byte for byte. If a source file is already corrupted, VERIFY can faithfully help write that corrupted content and still report success. If both the original and the copy are altered in the same way before comparison, a post-copy check against the original alone may not reveal which copy is authoritative.

For a simple copy test, retain the source, copy to a separate destination, and compare afterward:

VERIFY ON
COPY C:\INSTALL\DRIVER.ZIP D:\TEST\DRIVER.ZIP
FC /B C:\INSTALL\DRIVER.ZIP D:\TEST\DRIVER.ZIP

Use an independently trusted checksum file where one is published by the software’s maintainer. A comparison performed after copying tests equality of the two current files; it does not authenticate who published them. Keep at least one backup disconnected from the system being tested, and verify restore procedures rather than assuming that a successful write proves a recoverable backup.

Performance and scope tradeoffs

Verification can add reads to writes and can substantially slow storage that is already slow. On a floppy drive, the head may need to revisit the written data; on a virtual disk the extra work can be less visible but still adds host I/O. For a short test of questionable media, that tradeoff may be useful. For routine large copies, the additional time may be better spent on an explicit post-copy comparison that provides a clear pass/fail result and can be logged.

The VERIFY flag is not a disk-wide scrub. It does not scan all existing files, inspect unused sectors, repair FAT chains, examine bad clusters, or test all geometry. A filesystem check such as CHKDSK has a different purpose; a hardware diagnostic has a different purpose again. Do not run repair tools on the only copy of important data before capturing an image, especially when the symptom may be physical media failure.

Controlled diagnostic procedure

Use VERIFY as a controlled variable when diagnosing one destination:

Preserve the source on a separate known-good device and create or snapshot a disposable destination.
Record the current verify state with VERIFY and note the FreeDOS kernel, shell, and device driver configuration.
Copy a known test file with verification enabled. Record the complete output and elapsed time; do not treat the lack of an error message as a full integrity proof.
Run FC /B against the retained source and destination. If a trusted published hash exists, verify that independently with an appropriate checksum tool.
Repeat only if needed with VERIFY disabled to compare behavior, using the same source, destination, and test data. Do not repeat a test on a disk that has begun reporting errors.
Restore the original verify setting and document which layer produced the error: DOS write, read-back comparison, file comparison, or external checksum.

If a write fails only with VERIFY enabled, that is a strong clue that the write/read path is inconsistent, but it does not identify whether the cause is media, cable, controller, driver, or emulation. If it fails in both modes, first preserve data and test another known-good destination. If it succeeds with VERIFY but a later FC /B finds a difference, investigate read timing, source stability, memory corruption, and the device stack.

Batch files and state discipline

Because VERIFY changes shared DOS state, a batch script should not toggle it casually and forget the prior value. DOS batch languages do not provide a universally portable way to capture the setting and restore it automatically across all shells. For a human-operated procedure, record the initial state and restore it explicitly. If a production script requires deterministic behavior, make the assumed kernel and shell part of its support contract and test the script on those exact versions.

Avoid interpreting VERIFY as an error-level result from the last file write. It is a state-control command, not an integrity report command. For comparisons, use the documented FC exit codes: zero when files match, one when at least one pair differs, and distinct nonzero values for command, file, or open errors. DOS batch IF ERRORLEVEL n tests whether the result is at least n, so check higher errors before lower values.

Practical acceptance criteria

For a reliability test, define the required evidence in advance. A reasonable file-copy acceptance check is: expected source identity, completed copy without DOS errors, an exact byte comparison or trusted digest match, and a successful restore test from the backup location. VERIFY can strengthen the write phase when the target kernel supports it, but it cannot replace any of those checks.

For ordinary interactive use, leave the system in its expected operating state after the test and keep a note of any unusual I/O errors. If errors recur, do not turn verification off to make the warning disappear. That changes detection behavior, not the health of the medium. A careful operator treats the flag as a diagnostic instrument and treats independent read-back and backup evidence as the actual acceptance test.

Related:

Sources: