How to set "Verify On" at XP startup ?

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

On Sat, 6 Dec 2008 23:45:13 +0000 (UTC), chuckcar
wrote:

Hari Hari Mau wrote in
:

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.

I am looking for a way to do such a thing on XP.

I tried setting up a script at the startup/shutdown script, hoping
that when the machine is booted up, the "verify on" option would be
loaded. Apparently what I did failed miserably.

So I am here looking for help.

Can any of you Gurus tell me how to automate this "verify on" thing
for XP, so that every time the PC is booted, XP loads in the "verify
on" thing automatically, resulting in each and every copy / move
operation are verified bit-by-bit ?

Would be very appreciative of any of your suggestion and/or opinion.

Found this link:

http://www.computerhope.com/verifyhl.htm

The exact same method is used in *every* MS OS since MSDOS. That is, just
put a line:

verify on

in a file called autoexec.bat in the root directory of your C: drive and
enable autoexcec.bat in msconfig.

This claimes to answer my question too.

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

"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

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



(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?
But could you tell us *why* you want to have each file being written
read back to memory to verify that it was correctly written?

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.

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 :-(

I am looking for a way to do such a thing on XP.

I suppose you want windows to allways read back written files after
each drag-n-drop with windows filemanager and other programs to your
dusty diskettes or broken usbmemory to verify correct writings... hmm...

it seems that you crossposted to comp.os.ms-windows.programmer.win32
allso, so I guess you are interested in a solution where you
modify some core part of windows to make it fullfill your dreams.
personally I haven't done such disassembler things, but there are
people at msfn who have patched win98's kernel32.dll to fix handling
of larger files and things... if you was using win98 then perhaps that
would be the file you should extend with rereading&comparing stuff.
all the writebehind caching must perhaps be turned off somewhere else.

Would be very appreciative of any of your suggestion and/or opinion.

I suggest you use win98 instead, since the post is here you must
deep down have a wish to run win98, right? ;-)

(not that it would solve your "problem", but I kind of have
that opinion anyway hehe)

"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