How to set "Verify On" at XP startup ?

[John John (MVP)]

In Vista, /V for Xcopy is documented as:

/V Verifies the size of each new file.

Something it in fact does. (Well, it calls the right command after
the copy is completed only if you specify /V, I didn't dig deep enough to
verify it does anything with the call).

/V, at least according to the command line help, is documented in XP
as:

/V Verifies each new file.

Look in the Command Reference help files and it will tell you otherwise.

Though, even with that wording it behaves the same was in XP as it
does in Vista.

No, it doesn't!

Remarks

* Using /v

Windows XP does not use this command. It is accepted only for
compatibility with MS-DOS files.

http://technet.microsoft.com/en-us/library/bb491035.aspx


It's just calling an API presumably to get the file

size, not the sequence it would need to call to verify its contents.

The switch is completely ignored on Windows XP, and if an API is being
called to verify the file then that is "inherent to the operating
system" so Windows Explorer would also do the same thing! I don't
dispute that the switch might work on Vista, but it does nothing on
prior NT versions.

Interesting. The online help and the command line help don't agree.

Because the help in the command wasn't updated, it does work that way on
legacy W9x operating systems.

John

 

[Scott Seligman]

No, it doesn't!

You can quote help files all day. I'm telling you what it does, where
it calls a function to verify the length, on XP and Vista, only if the
/V option is specified. Without that option, XCopy does not call the
function.

Furthermore, I just verified it really does something with the results
of that function. I used Detours to modify the behavior of the function
it's using to find the file size to return the wrong file size. Without
/V, nothing happened, since it never called the function. With /V, xcopy
reported "File verification failed.". This was the behavior on both XP
and Vista.

In other words, /V does in fact verify the file size (but not the file
contents) on both XP and Vista.

 

[John John (MVP)]

You can quote help files all day. I'm telling you what it does, where
it calls a function to verify the length, on XP and Vista, only if the
/V option is specified. Without that option, XCopy does not call the
function.

Furthermore, I just verified it really does something with the results
of that function. I used Detours to modify the behavior of the function
it's using to find the file size to return the wrong file size. Without
/V, nothing happened, since it never called the function. With /V, xcopy
reported "File verification failed.". This was the behavior on both XP
and Vista.

In other words, /V does in fact verify the file size (but not the file
contents) on both XP and Vista.

I don't care what you say the Xcopy /v switch does *NOT* work on Windows
NT/XP/2000! And furthermore, I made a mistake in my previous post, the
switch is also ignored with Windows 9x!
http://support.microsoft.com/kb/128756

I don't care what it does with Vista or Server 2008, in any case, in
these operating systems the utility has been deprecated for Robocopy.

As for NT/2000/XP you can can argue all you want, unless you can provide
Microsoft documentation to refute the one that I presented you won't
convince me to that the switch works on these operating systems. And by
the way, your insistance that this switch does work would render your
first test (with Process Explorer/Filemon) invalid, if Xcopy does use
the switch the results aren't showing in Filemon, your test is flawed
and you have not proven that Explorer doesn't verify its file copies.

John

 

[Scott Seligman]

As for NT/2000/XP you can can argue all you want, unless you can provide
Microsoft documentation to refute the one that I presented you won't
convince me to that the switch works on these operating systems.

So, in other words, if the documentation is wrong, you don't care what
the programs actually do? That's fine, but I'm just pointing out what
Xcopy really does, not what the help files claim in does (Heck, even
it's own built in help claims it does something with /V, but in this
case, what it claims on XP is wrong).

I'm more than happy to agree that the switch was supposed to do
nothing at some point, but it in fact does do work.

And by
the way, your insistance that this switch does work would render your
first test (with Process Explorer/Filemon) invalid, if Xcopy does use
the switch the results aren't showing in Filemon, your test is flawed
and you have not proven that Explorer doesn't verify its file copies.

What? I'm not talking about Explorer. As I've mentioned it doesn't
verify the contents (as verified with Process Monitor, on XP and
Vista). It may verify the file size, but then again, it could just be
getting the file size after the copy because it's getting the size
information when it adds a file to a list.

As for my results with Xcopy, below are two different runs. Have you
seen something different? As you can see, the second run gets the
file information after it's copied, and as I determined with Detours,
it actually does care if that doesn't match what it was originally.

I'd also be happy to share my Detours project if you'd like.

C:\sourcedir>dir
Volume in drive C has no label.
Volume Serial Number is 0085-AAC7

Directory of C:\sourcedir

12/08/2008 09:51 AM <DIR> .
12/08/2008 09:51 AM <DIR> ..
12/08/2008 09:39 AM 2,744,087 example
1 File(s) 2,744,087 bytes
2 Dir(s) 19,497,865,216 bytes free

C:\sourcedir>xcopy * ..\testdir
1) CreateFile - C:\testdir
2) QueryDirectory - C:\testdir
3) QueryDirectory - C:\testdir
4) CloseFile - C:\testdir
5) CreateFile - C:\testdir\EXAMPLE
6) QueryDirectory - C:\testdir
7) QueryDirectory - C:\testdir
8) QueryDirectory - C:\testdir
9) CreateFile - C:\testdir
10) SetBasicInformationFile - C:\testdir
11) CloseFile - C:\testdir
12) CreateFile - C:\testdir
13) QueryDirectory - C:\testdir\example
14) CloseFile - C:\testdir
15) CreateFile - C:\testdir\example
16) CreateFile - C:\testdir
17) CloseFile - C:\testdir
18) QueryAttributeInformationVolume - C:\testdir\example
19) QueryBasicInformationFile - C:\testdir\example
20) SetEndOfFileInformationFile - C:\testdir\example
21) SetBasicInformationFile - C:\testdir\example
22) WriteFile - C:\testdir\example
23) ... WriteFile repeated ... - C:\testdir\example
63) WriteFile - C:\testdir\example
64) SetBasicInformationFile - C:\testdir\example
65) CloseFile - C:\testdir\example
66) QueryOpen - C:\testdir\example
67) CreateFile - C:\testdir\example
68) SetBasicInformationFile - C:\testdir\example
69) CloseFile - C:\testdir\example
70) CreateFile - C:\testdir
71) QueryDirectory - C:\testdir\example
72) CloseFile - C:\testdir
73) CreateFile - C:\testdir\example
74) SetBasicInformationFile - C:\testdir\example
75) CloseFile - C:\testdir\example


C:\sourcedir>xcopy /v * ..\testdir
1) CreateFile - C:\testdir
2) QueryDirectory - C:\testdir
3) QueryDirectory - C:\testdir
4) CloseFile - C:\testdir
5) CreateFile - C:\testdir\EXAMPLE
6) QueryDirectory - C:\testdir
7) QueryDirectory - C:\testdir
8) QueryDirectory - C:\testdir
9) CreateFile - C:\testdir
10) SetBasicInformationFile - C:\testdir
11) CloseFile - C:\testdir
12) CreateFile - C:\testdir
13) QueryDirectory - C:\testdir\example
14) CloseFile - C:\testdir
15) CreateFile - C:\testdir\example
16) CreateFile - C:\testdir
17) CloseFile - C:\testdir
18) QueryAttributeInformationVolume - C:\testdir\example
19) QueryBasicInformationFile - C:\testdir\example
20) SetEndOfFileInformationFile - C:\testdir\example
21) SetBasicInformationFile - C:\testdir\example
22) WriteFile - C:\testdir\example
23) ... WriteFile repeated ... - C:\testdir\example
63) WriteFile - C:\testdir\example
64) SetBasicInformationFile - C:\testdir\example
65) CloseFile - C:\testdir\example
66) QueryOpen - C:\testdir\example
67) CreateFile - C:\testdir\example
68) SetBasicInformationFile - C:\testdir\example
69) CloseFile - C:\testdir\example
70) CreateFile - C:\testdir
71) QueryDirectory - C:\testdir\example
72) CloseFile - C:\testdir
73) CreateFile - C:\testdir\example
74) SetBasicInformationFile - C:\testdir\example
75) CloseFile - C:\testdir\example
76) CreateFile - C:\testdir
77) QueryDirectory - C:\testdir\example
78) CloseFile - C:\testdir

 

[HeyBub]

Because the help in the command wasn't updated, it does work that way
on legacy W9x operating systems.

It's actually more insidious. On a DOS system, copy a large file to a
floppy, timing the process. Say it takes 30 seconds. Do it again, this time
with the /V switch.

After 30 seconds, the hard drive light goes out and the floppy light stays
on for another half-minute. This indicates that the OS is re-reading the
floppy drive to check the integrity of the copy.

Now fire up Win95 (or Win98) and repeat the experiment. It will still take
only 30 seconds to copy the file, with or without the /V switch. Methinks
Widows is verifying the copy of the file in memory, not on the target
medium.

However, COMP {filename1} {filename2} does work as expected in DOS, Win9x,
and XP - that is the target is actually compared to the source without
regard for what's in RAM.

 

[John John (MVP)]

So, in other words, if the documentation is wrong, you don't care what
the programs actually do? That's fine, but I'm just pointing out what
Xcopy really does, not what the help files claim in does (Heck, even
it's own built in help claims it does something with /V, but in this
case, what it claims on XP is wrong).

I'm more than happy to agree that the switch was supposed to do
nothing at some point, but it in fact does do work.




What? I'm not talking about Explorer. As I've mentioned it doesn't
verify the contents (as verified with Process Monitor, on XP and
Vista). It may verify the file size, but then again, it could just be
getting the file size after the copy because it's getting the size
information when it adds a file to a list.

And does Xcopy /v (as verified with Process Monitor) show it as
verifying the copy operation? No? So why then, based on your Process
Monitor test, would you claim that Explorer doesn't verify its copy
operations yet insist that Xcopy does, when in fact Process Monitor
shows it as doing the same thing as Explorer?

As for my results with Xcopy, below are two different runs. Have you
seen something different? As you can see, the second run gets the
file information after it's copied, and as I determined with Detours,
it actually does care if that doesn't match what it was originally.

I'd also be happy to share my Detours project if you'd like.

I don't need to see your Detours project, the xcopy /v switch is only
accepted for compatibility with MS-DOS programs, what is being returned
is irrelevant, it is only done and returned to be passed on to MS-DOS
programs, to make them believe that the switch actually does something
and to keep them from throwing an error! The file copy verification is
inherent to the operating system, it is done deeper down inside the
operating system architecture. Once again, from Server 2003
information, revised in 2005:

* Using /v

Windows XP and the Windows Server 2003 family of products do not use
this command. It is included only to preserve compatibility with
existing MS-DOS files, but it has no effect at the command line because
the functionality is automatic.

http://technet.microsoft.com/en-us/library/cc773364.aspx

Just because you have thrown a hastily designed test together it doesn't
mean that the Xcopy /v switch works in XP or that Windows Explorer
doesn't verify its file copies.

Call me incredulous, but what you are asking me to believe is that *all*
the documentation provided by Microsoft on this subject, up to and
including Server 2003 documentation, is wrong and that you are right.
I'm sorry but I just don't buy it. Your test does nothing to convince
me that Windows XP uses the /v switch for anything other than MS-DOS
compatibility and it does even less to convince me that the verify
operation isn't inherent to the operating system, and that by that very
nature that Explorer.exe doesn't use the same inherent verification
method, it does because *all* the native file copy utilities use the
same file copy functions!

John

 

[Scott Seligman]

And does Xcopy /v (as verified with Process Monitor) show it as
verifying the copy operation? No? So why then, based on your Process
Monitor test, would you claim that Explorer doesn't verify its copy
operations yet insist that Xcopy does, when in fact Process Monitor
shows it as doing the same thing as Explorer?

I'm not saying Xcopy /v verifies the operation. I'm just saying Xcopy
/v checks the final file size. It does something, however trivial,
and Xcopy behaves slightly differently from Xcopy /v. That's it.

I don't really have the patience to test if Explorer is doing the same
sort of file size verification. It might be, or it might not, a
Process Monitor log isn't enough to check that out.

Call me incredulous, but what you are asking me to believe is that *all*
the documentation provided by Microsoft on this subject, up to and
including Server 2003 documentation, is wrong and that you are right.

Then how do you explain that "Xcopy /v" does something, and returns an
error when "Xcopy" without the /v switch does? The documentation
that you're referencing clearly states it doesn't do anything, when
it clearly does.

I'm not saying it actually verifies the contents, but it does in fact,
at least in the scenarios I've tested, verify the file size after the
copy is done, and does something with the results of that test.

 

[John John (MVP)]

I'm not saying Xcopy /v verifies the operation. I'm just saying Xcopy
/v checks the final file size. It does something, however trivial,
and Xcopy behaves slightly differently from Xcopy /v. That's it.

I don't really have the patience to test if Explorer is doing the same
sort of file size verification. It might be, or it might not, a
Process Monitor log isn't enough to check that out.




Then how do you explain that "Xcopy /v" does something, and returns an
error when "Xcopy" without the /v switch does? The documentation
that you're referencing clearly states it doesn't do anything, when
it clearly does.

You are the one who said that Xcopy does thing differently with the /v
switch than it does without, not me. All I am telling you is that the
/v switch is only accepted for compatibility with MS-DOS and that if it
"appears" to be doing things differently it is only a "smoke show" to
fool MS-DOS applications into believing that the switch actually does
something. All of the Microsoft documentation on this switch clearly
states that the switch is ignored (does nothing) and that what the
switch is supposed to do is already inherent to the operating system,
that Xcopy does this automatically with or without the switch.

John

 

[Scott Seligman]

You are the one who said that Xcopy does thing differently with the /v
switch than it does without, not me. All I am telling you is that the
/v switch is only accepted for compatibility with MS-DOS and that if it
"appears" to be doing things differently it is only a "smoke show" to
fool MS-DOS applications into believing that the switch actually does
something.

It does something different, even if it's trivial. It can in fact cause
Xcopy to return an error as it checks the file size. If you refuse to
believe me and refuse to see for yourself, then I can't help you. The
switch is clearly not ignored. I've proven that to you, and you ignored
the evidence, and the offer to see the Detours test that shows the error
Xcopy can raise only with the /V switch.

Once again, I've shown you a different set of APIs that Xcopy calls
when you give it the /V switch. Do you think I'm making up test
results?

All of the Microsoft documentation on this switch clearly
states that the switch is ignored (does nothing) and that what the
switch is supposed to do is already inherent to the operating system,
that Xcopy does this automatically with or without the switch.

The documentation is wrong, then (or Xcopy has a bug, pick one, I
don't care). Maybe NT does do some sort of verify when it writes,
though I've never seen this documented in WriteFile() and friends, and
I just missing it in the API documentation?

 

[John John (MVP)]

It does something different, even if it's trivial. It can in fact cause
Xcopy to return an error as it checks the file size. If you refuse to
believe me and refuse to see for yourself, then I can't help you. The
switch is clearly not ignored. I've proven that to you, and you ignored
the evidence, and the offer to see the Detours test that shows the error
Xcopy can raise only with the /V switch.

Once again, I've shown you a different set of APIs that Xcopy calls
when you give it the /V switch. Do you think I'm making up test
results?




The documentation is wrong, then (or Xcopy has a bug, pick one, I
don't care). Maybe NT does do some sort of verify when it writes,
though I've never seen this documented in WriteFile() and friends, and
I just missing it in the API documentation?

If you think that there is a bug in Xcopy then submit your bug to Microsoft.

The API's might be documented but what the operating system does with
the API calls after it receives them is mostly a closely guarded secret,
how files are really copied and verified deep down inside the operating
system is probably not something that programmers need to know so unless
you want to sign a Non Disclosure Agreement Microsoft will probably not
tell you what goes on after the API call is made.

The Xcopy /v switch information has been consistent for more than 10
years now, from at least NT 4.0 up to and including Server 2003 *all*
the documentation has stated the same thing about the switch's usage.
If you think that Microsoft has been wrong about this all along then
here again I submit that you should contact them and ask them to correct
the errors in their documentation, they may ignore requests to correct
documentation about old Windows versions but I am sure that they would
certainly correct Server 2003 documentation. Until they correct their
documentation I will continue to believe what they say about the
switch's use.

John

 

[Scott Seligman]

The Xcopy /v switch information has been consistent for more than 10
years now, from at least NT 4.0 up to and including Server 2003 *all*
the documentation has stated the same thing about the switch's usage.

Not all. Xcopy /? doesn't agree with the documentation you've
referenced.

Why is one more correct than the other?

 

[John John (MVP)]

Not all. Xcopy /? doesn't agree with the documentation you've
referenced.

Why is one more correct than the other?

Microsoft will tell you that when you advise them of their documentation
error. Then they will have to package two different utilities, or two
different help files and have Xcopy figure out which help files to dish
out depending on whether the documentation is read inside the NTVDM or
at the 32-bit CLI.

 

[John John (MVP)]

switch than it does without, not me. All I am telling you is that the
/v switch is only accepted for compatibility with MS-DOS and that if
it "appears" to be doing things differently it is only a "smoke show"
to fool MS-DOS applications into believing that the switch actually
does something. All of the Microsoft documentation on this switch
clearly states that the switch is ignored (does nothing) and that what
the switch is supposed to do is already inherent to the operating
system, that Xcopy does this automatically with or without the switch.

[]
Surely compatibility would only be not giving an error message if you
invoke the /v switch? I find it difficult to believe they'd make the
command actually _operate_ differently (as I'm satisfied he has shown),
if compatibility was all they were worried about: surely they'd just
make it ignore whether the switch was there or not, or at least not make
it generate an error message such as "invalid switch".

Whether the command in question uses completely different code to the
copy/move functions intrinsic to the OS, I don't know.

I'm guessing, but if a 16-bit program asks to use the /v switch it might
want to wait or follow operating system routines to make sure that the
command completes successfully, as far as I'm concerned the /v switch is
just doing a smoke show to convince programs running inside the NTVDM
that the switch is doing something and to prevent the 16-bit programs
from choking. If you think its doing something else then use the switch
and be happy or join in with others and submit your findings to
Microsoft. All I know is that Microsoft has been telling us for about
15 years that the switch does nothing on NT versions up to Server 2003,
(and according to http://support.microsoft.com/kb/128756 it also doesn't
do anything on the legacy W9x systems), I'm having a hard time believing
that this information is wrong and has gone on uncorrected for that
long. On Vista and Server 2008 Microsoft simply tells us the utility is
deprecated.

John

 

[Hari Hari Mau]

So, in other words, if the documentation is wrong, you don't care what
the programs actually do? That's fine, but I'm just pointing out what
Xcopy really does, not what the help files claim in does (Heck, even
it's own built in help claims it does something with /V, but in this
case, what it claims on XP is wrong).

I'm more than happy to agree that the switch was supposed to do
nothing at some point, but it in fact does do work.


What?  I'm not talking about Explorer.  As I've mentioned it doesn't
verify the contents (as verified with Process Monitor, on XP and
Vista).  It may verify the file size, but then again, it could just be
getting the file size after the copy because it's getting the size
information when it adds a file to a list.

As for my results with Xcopy, below are two different runs.  Have you
seen something different?  As you can see, the second run gets the
file information after it's copied, and as I determined with Detours,
it actually does care if that doesn't match what it was originally.

I'd also be happy to share my Detours project if you'd like.

C:\sourcedir>dir
 Volume in drive C has no label.
 Volume Serial Number is 0085-AAC7

 Directory of C:\sourcedir

12/08/2008  09:51 AM    <DIR>          .
12/08/2008  09:51 AM    <DIR>          ..
12/08/2008  09:39 AM         2,744,087 example
               1 File(s)      2,744,087 bytes
               2 Dir(s)  19,497,865,216 bytes free

C:\sourcedir>xcopy * ..\testdir
1) CreateFile - C:\testdir
2) QueryDirectory - C:\testdir
3) QueryDirectory - C:\testdir
4) CloseFile - C:\testdir
5) CreateFile - C:\testdir\EXAMPLE
6) QueryDirectory - C:\testdir
7) QueryDirectory - C:\testdir
8) QueryDirectory - C:\testdir
9) CreateFile - C:\testdir
10) SetBasicInformationFile - C:\testdir
11) CloseFile - C:\testdir
12) CreateFile - C:\testdir
13) QueryDirectory - C:\testdir\example
14) CloseFile - C:\testdir
15) CreateFile - C:\testdir\example
16) CreateFile - C:\testdir
17) CloseFile - C:\testdir
18) QueryAttributeInformationVolume - C:\testdir\example
19) QueryBasicInformationFile - C:\testdir\example
20) SetEndOfFileInformationFile - C:\testdir\example
21) SetBasicInformationFile - C:\testdir\example
22) WriteFile - C:\testdir\example
23) ... WriteFile repeated ... - C:\testdir\example
63) WriteFile - C:\testdir\example
64) SetBasicInformationFile - C:\testdir\example
65) CloseFile - C:\testdir\example
66) QueryOpen - C:\testdir\example
67) CreateFile - C:\testdir\example
68) SetBasicInformationFile - C:\testdir\example
69) CloseFile - C:\testdir\example
70) CreateFile - C:\testdir
71) QueryDirectory - C:\testdir\example
72) CloseFile - C:\testdir
73) CreateFile - C:\testdir\example
74) SetBasicInformationFile - C:\testdir\example
75) CloseFile - C:\testdir\example

C:\sourcedir>xcopy /v * ..\testdir
1) CreateFile - C:\testdir
2) QueryDirectory - C:\testdir
3) QueryDirectory - C:\testdir
4) CloseFile - C:\testdir
5) CreateFile - C:\testdir\EXAMPLE
6) QueryDirectory - C:\testdir
7) QueryDirectory - C:\testdir
8) QueryDirectory - C:\testdir
9) CreateFile - C:\testdir
10) SetBasicInformationFile - C:\testdir
11) CloseFile - C:\testdir
12) CreateFile - C:\testdir
13) QueryDirectory - C:\testdir\example
14) CloseFile - C:\testdir
15) CreateFile - C:\testdir\example
16) CreateFile - C:\testdir
17) CloseFile - C:\testdir
18) QueryAttributeInformationVolume - C:\testdir\example
19) QueryBasicInformationFile - C:\testdir\example
20) SetEndOfFileInformationFile - C:\testdir\example
21) SetBasicInformationFile - C:\testdir\example
22) WriteFile - C:\testdir\example
23) ... WriteFile repeated ... - C:\testdir\example
63) WriteFile - C:\testdir\example
64) SetBasicInformationFile - C:\testdir\example
65) CloseFile - C:\testdir\example
66) QueryOpen - C:\testdir\example
67) CreateFile - C:\testdir\example
68) SetBasicInformationFile - C:\testdir\example
69) CloseFile - C:\testdir\example
70) CreateFile - C:\testdir
71) QueryDirectory - C:\testdir\example
72) CloseFile - C:\testdir
73) CreateFile - C:\testdir\example
74) SetBasicInformationFile - C:\testdir\example
75) CloseFile - C:\testdir\example
76) CreateFile - C:\testdir
77) QueryDirectory - C:\testdir\example
78) CloseFile - C:\testdir

Do tell us more about your "Detours" project.

I surely can learn something out of it !!

Thanks in advance !!

 

[Scott Seligman]

Do tell us more about your "Detours" project.

I surely can learn something out of it !!

http://research.microsoft.com/en-us/projects/detours/