How to set "Verify On" at XP startup ?

teebo wrote in newsp.ulutr4z4br8ivg@300pl:

"Tells Windows whether to verify that your files are written correctly
to a disk." So it's a DOS command that instructs Windows.

similar to environment variables that also can be set from a dos command
but used by windows

I wonder why there is 6 -posts here (and a small spam inbetween) but
no starting post that they would be grouped under.... I suppose the
original
post is only to "24hoursupport.helpdesk" (someone that can tell me what
that is?) and only have followup set to here? (sounds very strange to
me)

You're blocking Google groups perhaps?

Here's the original post:

Message-ID:



(back to the original posters question now, if he is reading
In Win98, an "verify on" entry inside the autoexec.bat batch file
ensures that each and every copy operation is being done by bit-by-bit
verification.

the phrase "bit-by-bit" is perhaps a bit ;-) strange, you don't say
"bit-by-bit copying" when you copy a file do you?

Turn of the phrase. It copies the buffer (64KB for xcopy) and then checks
each byte. Same difference. You check 8 data bits and the checksum on the
harddrive (usually 2 bits and completely transparent) at the same time.

If you don't trust your harddisk then I would trash it and
buy a new one. besides, the read-back verifications is probably
only reporting back what the harddisks internal cache have in
memory and isn't at all read from the disk.

That's making assumptions on how MS wrote the code. They also wrote the
code for disk writing, so it's a pretty big assumption.

IMHO the only real use for verify on is with floppys, and well...
you don't write important things to floppy today I hope?
(yes I did backups to floppys too ones.... but that was before
the cd existed)

But wait...
http://support.microsoft.com/kb/126457

That KB articles says it only applies to MS-DOS 3.1 - 6.22 but if I
understand it right VERIFY ON is/was even more useless than I thought
since it doesn't do a compare - only a quick badsector-check :-(

My link states that it works for *any* version of MS OS (the applicable
"D" left out to stop confusion). Including the NT family. It's commonly
used in MSDOS. After 6.22 MS didn't call it that any more. Even though it
still technically *is* a DOS.

Understand, that none of the above was knocking you, just clarifying for
the OP.


--
(setq (chuck nil) car(chuck) )

"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

Scott Seligman wrote:

"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?

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

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

--
--------- Scott Seligman scott at firstname and michelle dot net ---------
A free society is a place where it's safe to be unpopular.
-- Adlai Stevenson

In message , "John John (MVP)"
writes:
[]
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.
--
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. **

"Bugger," said Pooh, feeling very annoyed.

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

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?

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.

J. P. Gilliver (John) wrote:

In message , "John John (MVP)"
writes:
[]

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

On 8 Dec 2008 07:29:33 -0800, "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.".

Well, that's not good.

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.