# Solved: Verifying copied files in ms-dos



## mjf10025 (Oct 29, 2008)

Does anyone know of an ms-dos environment file-copying utility which would confirm the accuracy of its copies? I'd like to use this utility in a batch file. VERIFY ON or using the /V switch for COPY or XCOPY doesn't actually compare all the bits of the duplicate. My large dBASE files are often not copying accurately, and I'd like to catch that without having to test every copied file myself with the fc command. Backup software would be a tedious way to go, as my goal is mirroring rather than backing up.


----------



## jdean (Jan 20, 2002)

Do you really mean an MS-DOS application or do you mean you want to be able to run it from the command line? If the latter, you might try SyncBack, which has a Windows interface but once you've set up a profile, you should be able to run it from the command line.

On the other hand, if your files are not being copied accurately, you have a more serious problem. Are you sure that your database is not in use when the copying is being done? You might want to do some more investigation to determine the cause of the problem.


----------



## mjf10025 (Oct 29, 2008)

Thanks for the reply. My hope really is for a windows-independent utility or command. I don't even have a version of windows installed on the computers running my old DOS software. 

The files copy correctly 95% of the time. So I get lulled into a false sense of security. And then, every few months, when I'm no longer anticipating it, I'll find the copy is corrupted.


----------



## jdean (Jan 20, 2002)

I'm suggesting that you try to determine the cause of the corruption. If your backup media is going bad, you should be thinking about replacing it because it's possible that a copy will verify but then go bad later on,

Are you certain that the database is not being used by any program when you do the backup?


----------



## TheOutcaste (Aug 8, 2007)

Why not just use FC in the batch file?
Any copy utility that verifies files the way you want will be doing a file compare, same as FC does, so might as well just use it. You can script it to retry X number of times after a verify fails, or just log the error in a file, or make noise to get attention.

A 2nd batch file to compare the files might be a good idea too. After verifying the files copied OK, you can run this batch every few days to see if the files are going bad sometime after they are copied. If they are, then as jdean says, you need to find out why.

Jerry


----------



## mjf10025 (Oct 29, 2008)

jdean: great advice. Tinkering, today, I found that files I thought were corrupted were actually fine but not being properly read. When I called the files from my hard drive, rather than loading them first into RAM & using them from there, they read perfectly. So I spent the evening tweaking my programs to read and write entirely from the hard drive and I'm hopeful this solves the problem. I'll continue to use xcopy + verify on.
Thanks again.

The Outcaste: didn't know FC worked in a batch file. When I run it from the command line, I get a stream of binary numbers rather than a "yes/no" returned variable. Have you actually tried this? If so, might you post a sample of the instructions one might use? My application uses about 100 database files, and it would be *awesome *to be able to automate a comparison of the hard drive files with the Zip drive copies.


----------



## TheOutcaste (Aug 8, 2007)

Just check the exit code from FC. It will be 0 if the files match, 1 if they don't


```
@echo off
Set Source1=C:\test\
Set Source2=G:\Copies
For /F "tokens=*" %%A In ('Dir %Source1% /b /a-d') Do (
  FC "%Source1%%%A" "%Source2%%%A" >nul
  If ERRORLEVEL 1 (
    Echo File %%A does not match the copy
    ) else (
    Echo File %%A matches the copy
  )
)
```
This assumes the files are all in one folder and the names were not changed. It also assumes that all the files in Source1 exist in Source2. If the folders won't be identical, you need to add some checking to make sure the file exists in the Source2 folder
You can do whatever processing you want instead of just echoing the result.

You could also pipe the output of FC to Find and check for *no differences encountered*. If not found, the files don't match.
The Exit codes for Find:
F0und=0
M1ssing=1

HTH

Jerry


----------



## mjf10025 (Oct 29, 2008)

Jerry,
I'm extremely grateful. This should be hugely helpful. Can't wait to test it out. I'm going to wait a few days before marking my question as resolved, so I can shout for help if I have problems implementing this. Thanks again. 
Marty


----------



## jdean (Jan 20, 2002)

Shouldn't you use the FC /B option for a binary compare? These are database files, not text files.


----------



## TheOutcaste (Aug 8, 2007)

Good point jdean, it might be better, though it won't make a difference in the results for this use as both modes do the comparison the same way.

Other than the format with which differences are displayed, the difference in the modes is that Ascii mode tries to resync the two files after it finds a difference. If the files are very different, the internal buffer it uses to resync after a mismatch may overflow, which generates a resync error. Not sure of the error code, but it will be greater than 1, and the way the *If Errorlevel* statement works, it will still see that the files are different.

Since we are just interested in the fact that there is a difference, not in what those differences are, it really shouldn't matter. There might be a slight speed difference when comparing files that don't match, but it could go either way depending on what the differences are in the files being compared.

Of course, if everything is working right the files will always match, so it shouldn't make a difference. But if everything was working right this wouldn't be needed.

If you don't specify a mode, it will run in Ascii mode for all files except these extensions:
.*exe, .com, .sys, .obj, .lib, or .bin*

HTH

Jerry


----------



## jdean (Jan 20, 2002)

TheOutcaste said:


> Good point jdean, it might be better, though it won't make a difference in the results for this use as both modes do the comparison the same way.


Wrong. Try comparing two text files with the same contents except that one of which uses DOS end-of-line conventions (CR-LF) and the other of which uses Unix conventions (LF). If you omit the /B, FC will report the files as identical.


----------



## TheOutcaste (Aug 8, 2007)

You are absolutely right jdean. Don't know why I was thinking the two modes were the same.
Another difference is ASCII mode expands tabs to spaces, so it's possible to have one file using tabs and another using spaces to be reported as being identical when they aren't.
For example:
*test{tab}file* is the same as *test{4spaces}file*

Thanks for pointing that out:up:

Jerry


----------

