How to set "Verify On" at XP startup ?

In message , John Holmes
writes:
[]
Windows Explorer will always copy with verify ON

Quite apart from the doubts that others have expressed over the above
statement, do you mean just verify-that-the-written-file-can-be-read, or
verify-that-the-written-file-matches-the-source-file? (Someone in this
thread has pointed us to a MSKB article which says that the /v switch -
and verify on command - only does the first sort of verify.)
--
J. P. Gilliver. UMRA: 1960/1985 MB++G.5AL(+++)IS-P--Ch+(p)Ar+T[?]H+Sh0!:`)DNAf
** http://www.soft255.demon.co.uk/G6JPG-PC/JPGminPC.htm for ludicrously
outdated thoughts on PCs. **

"Does Barbie come with Ken?"
"Barbie comes with G.I. Joe. She fakes it with Ken." - anonymous

On Sun, 7 Dec 2008 13:05:39 +0000, "J. P. Gilliver
(John)" wrote:

In message , John Holmes
writes:
[]
Windows Explorer will always copy with verify ON

Quite apart from the doubts that others have expressed over the above
statement, do you mean just verify-that-the-written-file-can-be-read, or
verify-that-the-written-file-matches-the-source-file? (Someone in this
thread has pointed us to a MSKB article which says that the /v switch -
and verify on command - only does the first sort of verify.)

Apparently that post didn't make it to all the NGs
in the list. But if the claimed behavior is true,
it would indicate a change in the meaning of the
term "Verify" by Microsoft. Old DOS versions (I
have the v5.0 manual open in front of me) clearly
state that the /v switch or Verify On command
"Verifies each file as it is written to the
destination file to make sure that the destination
files are identical to the source files". And (to
respond to another post in this thread) this
parameter works (or worked in v5.0) in exactly the
same way for Xcopy.

Best regards,


Bob Masta

DAQARTA v4.51
Data AcQuisition And Real-Time Analysis
www.daqarta.com
Scope, Spectrum, Spectrogram, Sound Level Meter
FREE Signal Generator
Science with your sound card!

wrote:
files are identical to the source files". And (to
respond to another post in this thread) this
parameter works (or worked in v5.0) in exactly the
same way for Xcopy.

In Xcopy on XP and Vista, all /V does is verify the target file size.
It's incorrectly documented in XP, but in Vista the documentation has
changed to the following:

/V Verifies the size of each new file.


--
--------- Scott Seligman scott at firstname and michelle dot net ---------
The avalanche has already started. It is too late for the pebbles to
vote. -- Ambassador Kosh Naranek in Babylon 5:"Believers"

The reference you are using is wrong.

Please see:
http://support.microsoft.com/kb/126457
VERIFY ON, COPY /V, XCOPY /V Commands Do Not Compare Data
--
Jeff Richards
MS MVP (Windows - Shell/User)
"Scott Seligman" wrote in message
...
wrote:
files are identical to the source files". And (to
respond to another post in this thread) this
parameter works (or worked in v5.0) in exactly the
same way for Xcopy.

In Xcopy on XP and Vista, all /V does is verify the target file size.
It's incorrectly documented in XP, but in Vista the documentation has
changed to the following:

/V Verifies the size of each new file.


--
--------- Scott Seligman scott at firstname and michelle dot
net ---------
The avalanche has already started. It is too late for the pebbles to
vote. -- Ambassador Kosh Naranek in Babylon 5:"Believers"

Scott Seligman wrote:

"John John (MVP)" wrote:

So then we would have to conclude that other than the copy command none
of the other native file copy commands are capable of verifying the
copy operation?


No. I'm just saying by default Explorer doesn't verify the contents of
the copy operation by default. For all I know there's some way to enable
that behavior.

I have never heard of being able to change Explorer's copy behaviour.
Explorer.exe uses the same file copy functions as the other copy
utilities, it would be interesting to know how these functions verify
their copy operations.

I'm finding this a bit hard to believe, especially when Microsoft
tells us that the /v switch is ignored with Xcopy because the verify
operation is inherent to the operating system.


Where do they say that? /V in Xcopy isn't documented as verifying the
file contents, but rather verifying the file size, something it in fact
does if you specify the /V option.

Look in the Windows Help files. The Xcopy /v option is ignored by
Windows NT/2000/XP, it does nothing, it it is accepted only for
compatibility with MS-DOS. The Windows XP help files do not elaborate
any further but the Windows 2000 help files says:

" /v - Verifies each file as it is written to the destination file to
make sure that the destination files are identical to the source files.
This switch is ignored because the functionality is inherent to the
Windows 2000 operating system. The switch is accepted only for
compatibility with previous versions of MS-DOS."

By the same token, the obsolete MS-DOS VERIFY command is also ignored by
NT operating systems. This information is also present in Windows NT
4.0 documentation, I find it hard to believe that the same would not
apply to Windows XP, or for that matter Vista.

As it is, if we are to accept that Explorer doesn't verify its copy
operations, the only native tool that can verify its copy operations
would be the internal Copy command, there again I find it hard to
believe that any of the NT versions would simply do away with this for
all but the internal copy command.

John

"John John (MVP)" wrote:
Look in the Windows Help files. The Xcopy /v option is ignored by
Windows NT/2000/XP, it does nothing, it it is accepted only for
compatibility with MS-DOS. The Windows XP help files do not elaborate
any further but the Windows 2000 help files says:

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.

Though, even with that wording it behaves the same was in XP as it
does in Vista. It's just calling an API presumably to get the file
size, not the sequence it would need to call to verify its contents.

" /v - Verifies each file as it is written to the destination file to
make sure that the destination files are identical to the source files.
This switch is ignored because the functionality is inherent to the
Windows 2000 operating system. The switch is accepted only for
compatibility with previous versions of MS-DOS."

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

--
--------- Scott Seligman scott at firstname and michelle dot net ---------
It has been said that democracy is the worst form of government
except all the others that have been tried.
-- Sir Winston Churchill

Scott Seligman wrote:

"John John (MVP)" wrote:

Look in the Windows Help files. The Xcopy /v option is ignored by
Windows NT/2000/XP, it does nothing, it it is accepted only for
compatibility with MS-DOS. The Windows XP help files do not elaborate
any further but the Windows 2000 help files says:


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/l.../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.


" /v - Verifies each file as it is written to the destination file to
make sure that the destination files are identical to the source files.
This switch is ignored because the functionality is inherent to the
Windows 2000 operating system. The switch is accepted only for
compatibility with previous versions of MS-DOS."


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

"John John (MVP)" wrote:
Though, even with that wording it behaves the same was in XP as it
does in Vista.

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.

--
--------- Scott Seligman scott at firstname and michelle dot net ---------
We all agree on the necessity of compromise. We just can't agree on
when it's necessary to compromise.
-- Larry Wall

Scott Seligman wrote:
"John John (MVP)" wrote:

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

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.

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

"John John (MVP)" wrote:
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:\sourcedirdir
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:\sourcedirxcopy * ..\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:\sourcedirxcopy /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

--
--------- Scott Seligman scott at firstname and michelle dot net ---------
Money often costs too much.
-- Ralph Waldo Emerson

John John (MVP) wrote:


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.


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.

Scott Seligman wrote:
"John John (MVP)" wrote:

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.

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/l.../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

"John John (MVP)" wrote:
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.

--
--------- Scott Seligman scott at firstname and michelle dot net ---------
The most difficult thing in the world is to know how to do a thing
and to watch someone else do it wrong without comment.
-- Theodore H. White

Scott Seligman wrote:

"John John (MVP)" wrote:

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.

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

"John John (MVP)" wrote:
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?


--
--------- Scott Seligman scott at firstname and michelle dot net ---------
Never do today what you can put off till tomorrow. Delay may give
clearer light as to what is best to be done.
-- Aaron Burr