Windows 7 - wrote:<SNIP>Hi,I thought of another method after I posted my message.

Hi,
I thought of another method after I posted my message.

Note: I have several TEMP ("TEMP1", "TEMP2", etc.) folders/directories
on my computer's hard drive.

Copy a group of files (any type) to "TEMP1" folder until you have
exactly 1G total.

Via Command Prompt, enter "TEMP1" folder and type the command,
You just created a 1G file.   Enter TEMP2 and type the command,
additional 1G files.

If you have a 2G flash drive, copy two 1G files to it.  Then copy all
back to the hard drive into "TEMP3".

Use a file/s compare utility or the command "FC/B" to compare files
in TEMP2 to those in TEMP3.

Thanks again to everyone, John

You end up doing a lot of writes followed with a binary file compare to
ensure source and target copies are equal.  So how does that guarantee
that future writes will be perfect?  It does not.  All you have done is
exercise further oxide stress on the memory that wears it out, generates
errors that have to be masked out by mapping bad blocks to good blocks
and which incurs further delay that slows down performance, and
eventually the device catastrophically fails when there is no more
reserve space for the remapping.

If you are doing manually copies rather than, say, using backup software
that can perform a validity check after the backup operation then get
used to doing the binary file compare after doing your manual copying.
Reads are less stressful on flash memory than are writes.

Using a checksum command, such as md5sum, sha1sum, fciv (Microsoft) is
just as valid as a binary comparison, if you want to use it. A one bit
change, causes an entirely different checksum with those algorithms,
unlike the poorer quality coverage you would  get with the older "sum" command.

One failure I had on my USB key, was a "bad pointer" inside the key. I'd
zeroed the entire drive first, then created a file system and copied a
big file, and the checksum on the big file was wrong. Using a hex editor,
I "walked" through the file for a quick visual check, and found a 128KB
area of all zeros. Which means, one of the previous blocks I'd written,
showed up in the middle of the current file. The problem did not
reoccur. When these storage media use indirection, these kinds of things
can happen. Exactly where that failed information was stored (pointers
to blocks), I have no idea.

Paul