What does the /V (verify) flag to XCOPY mean, and how did it get that way?

The XCOPY command has a flag called /V, which stands for verify. Sort of.

  /V           Verifies the size of each new file.

First, the easy question: What does this flag do?

Answer: If this flag is set, then after a file is copied, the XCOPY program will verify that the source and destination files are the same size.

As you might surmise, this doesn't really get you much. On top of that, disk caching means that the file size it reads most likely did not come from the hard drive. It came from the disk cache. So it's essentially verifying that RAM is not corrupted, which is really not all that interesting.

But wait, why does this flag even exist, seeing as it's so lame as to be useless?

The XCOPY command got the /V option from the COPY command. You can even find remnants of that command today:

C:\> VERIFY /?
Tells cmd.exe whether to verify that your files are written correctly to a


Type VERIFY without a parameter to display the current VERIFY setting.
VERIFY is off.

What does it mean to "verify that your files are written correctly to a disk"?

What it means to CMD.EXE is that after copying each file, it goes back and rereads both the source and destination and performs a byte-for-byte comparison of the files. If any bytes differ, it reports an error.

And in the presence of disk caches, this comparison is largely useless, since both the source and destination are most likely still in the disk cache, so all this is doing is comparing two RAM buffers against each other, which has nothing to do with whether the file got written successfully to disk.

Okay, so why does COPY have this weird verify behavior?

All this rigamarole over "verifying" comes from MS-DOS. Normally, when MS-DOS wrote to the disk, it issued command 8 (write) to the device driver. But if you did a VERIFY ON, then MS-DOS would issue command 9 (write with verify) instead. Device drivers were expected to handle the "write with verify" command by writing the data to the disk, then reading the data back and comparing it to what should have been written.

At the end of the day, it was up to the device driver to do the verification. All that VERIFY ON did was set a flag that eventually made its way down to the device driver, who was expected to do something.

Okay, now let's run the time machine forward again. MS-DOS had this VERIFY ON thing. But in the new I/O model, there is no "write and verify" command. There's just "write". So CMD.EXE fakes it by doing its own verification: After copying a file, it reads it back. And XCOPY.EXE fakes it by simply checking whether the file sizes match. Neither of these fake verifications really accomplish much because of disk caching. But the options are there for backward compatibility.

Comments (16)
  1. Boris says:

    But what kind of compatibility issue would occur if cmd.exe were simply to accept but ignore the switch?

    1. Brian_EE says:

      One where if the disk cache buffers actually weren’t identical, and (x)copy said the file verified but then they really weren’t the same after flushing.

      While rare, RAM bits can get flipped. So at least checking the cache buffers you do the best you can before they flush to media.

  2. MacIn173 says:

    IIRC, it is not just ‘device driver would compare’ etc. “by writing the data to the disk, then reading the data back and comparing it to what should have been written. ”

    There’s special ‘verify’ command that is handled by floppy disk controller, and thing it does is to read the track(actually, either whole track or N sectors) and calc checksum.
    Command code is D6, the actual data is not transferred to the RAM, CRC code is checked in FDC for each sector.

    So, originally, what VERIFY ON does is to check if CRC of data in the sector corresponds to the CRC from sector header.

    1. MacIn173 says:

      Well, right. According to the sources of MS-DOS in public domain, VERIFY ON is translated into call #4 for int 13h, which is BIOS ‘verify’ that directly throws verify command to the FDC.

  3. So in the event that xcopy was used to copy data between two disks (using /W)… the assumption is that the file size would be sufficient?

    seems like floppy disk corruption would be the exact situation where byte-by-byte verification would benefit most.

  4. BZ says:

    So how useful was the /V switch by MS-DOS 6.2 days? Because we always used it when doing both floppy disk copy and HDD copying between different locations.

  5. HiTechHiTouch says:

    For once, a most disappointing telling of the story.

    Was there a fly on the wall when the “new I/O” model was hashed out who could tell us why hardware verification was tossed off so lightly to the device driver?

    How did the conversation go when the XCOPY developer decided to total subvert/redefine “verify” as used by the copy command (i.e. floppy CRC verification)? Remember, the original XCOPY intent was to do exactly what copy did, only do it by batching as much I/O together as possible so to reduce floppy disk swaps…

    And did the original software people who had suffered from bad media and realized they could build assistance into the operating system (/v, VERIFY) ever raise their voices when verification was gutted?

    If the history could be assembled, it would make a good case study in project evolution / programming psychology / inter-group communication failures.

    1. The MS-DOS version of XCOPY used the MS-DOS “verify” command, which did whatever MS-DOS did. It’s the Win32 version of XCOPY that was stuck with a /V flag that didn’t have equivalent semantics in Win32.

  6. Richard Wells says:

    By the time of DOS 6.22, the verify wasn’t exactly useful. Most systems had sufficient memory to make a sizable disk cache which concealed some of these errors.

    Now, if instead, one was back in the multitasking floppy only world of the PDP-11, verify was tremendously useful. The destination floppy might have damage and not record the file or the super long floppy cable might encounter noise. So DEC PIP had a verify option, CP/M PIP implemented the idea, and then DOS included equivalents to much of the CP/M feature set.

  7. In theory, the destination might allow write but not read; so xcopy /v would be a way to both copy the file and confirm read access on the destination, in a single command.

  8. exchange development blog team says:

    Uhh, what’s “command 8” and “command 9”? The only one I’m familiar with was AH=43h with AL=00 or 01 to control verify. In any case the “write with verify” option was always rather optimistic, the most frequently-applied way to implement it was to ignore the flag.

    1. MS-DOS device driver command codes are listed here.

  9. cheong00 says:

    Btw, the “Set Features” (EFh) command of ATAPI command supports subcommand “Enable Write-Read-Verify” (0BH) (command reference section 7.47.10). When set to mode 00H, it’ll make the disk verify written location is readable after each write without additional burden to the system. If the read after write fails, the controller will report error to the system. So I think the verify option is still feasible on HDD today too.

    Of cource the disk controller can lie and don’t do what it supposed to, but just like the controller can lie about what it does when you command it to do buffer flush, it doesn’t mean you can’t write feature rely on that when it’s needed.

    1. cheong00 says:

      Almost forgot it, the command sets global state on disk hence will slow down write performance on disk with head on other application as well during the setting is effective. I don’t think it’ll have any performance problem on SSD.

      Is there documentated way to enable this feature on my SSDs or it’s enabled by default now (I think on Win10 because SSDs are now becoming more common)?

  10. Neil says:

    Nowadays the only remaining use of VERIFY appears to be as a convenient way to set ERRORLEVEL so that you can detect whether SETLOCAL has taken effect.

  11. Ray Koopa says:

    Verifying must’ve been awfully slow back in the days of copying stuff to floppies, wasn’t it? =)

Comments are closed.

Skip to main content