XCOPY command has a flag called
which stands for verify.
/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,
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?
XCOPY command got the
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 disk. VERIFY [ON | OFF] Type VERIFY without a parameter to display the current VERIFY setting. C:\> VERIFY VERIFY is off.
What does it mean to "verify that your files are written correctly to a disk"?
What it means to
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
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
At the end of the day, it was up to the device driver to do the
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".
CMD.EXE fakes it by doing its own verification:
After copying a file, it reads it back.
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.