![]() |
If this is your first visit, be sure to check out the FAQ by clicking the link above. You may have to register before you can post: click the register link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below. |
|
|
Thread Tools | Display Modes |
#21
|
|||
|
|||
![]()
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 |
#22
|
|||
|
|||
![]()
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. |
#23
|
|||
|
|||
![]()
"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 |
#24
|
|||
|
|||
![]() 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 |
#25
|
|||
|
|||
![]()
"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 |
#26
|
|||
|
|||
![]()
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 |
#27
|
|||
|
|||
![]()
"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) |
#28
|
|||
|
|||
![]()
"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 |
#29
|
|||
|
|||
![]()
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. |
#30
|
|||
|
|||
![]()
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 |
Thread Tools | |
Display Modes | |
|
|
![]() |
||||
Thread | Thread Starter | Forum | Replies | Last Post |
Shutting off Keyboard Language Icon "EN" in systray "Internat.exe" | Dr. Dos | Disk Drives | 2 | July 11th 08 05:44 PM |
Networking Card 3Com "3C905B-TX": File "el90xbc5.sys" not found | MB[_2_] | Internet | 11 | August 10th 07 06:18 PM |
"Himem.sys fehlt", "Steuerung der A20-Leitung nicht möglich!!" - und dann nichts gewesen? | Alex Wenzel | General | 7 | March 8th 06 07:01 PM |
"Initial" Track on CD Rom Disk (Physical Stop or "Seek") | Brad | Disk Drives | 1 | February 28th 06 06:27 PM |
PDF File "NOT Valid win32 Application" for" My Documents" Double C | Dr. H.Mak | General | 12 | October 26th 05 07:50 PM |