I have been plagued by this problem for months; when copying large (2-15GB)
files from one drive to another, I find that the source and destination do
not match afterward when I run a binary comparison between them.

Originally I was transferring files between two XP machines over a gigabit
network. I attempted all possible combinations of drive mapping with no
effect. Occasionally a recopy *would* match, but often I got no improvement.

I am now transferring the files directly on the target machine, by attaching
the source hard drive to a spare SATA connection, with the same results. But
if I come back to it a day or so later, it may suddenly copy and compare just
fine.

The original configuration was XP-SP2 to XP-MCE-SP2. I'm now only on the MCE
machine, though I have installed SP3 as well as all current critical updates.
It is an Intel Core-2 Quad Q6600 with 4GB of RAM. I am running AVG v9 and
ZoneAlarm v7, and am using Beyond Compare 3 to verify the file transfers.
Sometimes the comparison fails almost immediately, other times near the end
of the file.

I've also run Spybot and several other anti-malware programs with no hits,
as well as memtest86 with no failures.

This is a relatively young machine; it was built a couple years ago but gets
fairly little use, mainly for bulk storage.

If anyone has any ideas or knows how I can fix this problem I would be most
grateful. It's been a constant annoyance and I can't find anything that would
explain it. At this point I'm out of ideas, other than junking it and
starting from scratch with new components.

Any help would be greatly appreciated.

Thanks!

J wrote:
> I have been plagued by this problem for months; when copying large (2-15GB)
> files from one drive to another, I find that the source and destination do
> not match afterward when I run a binary comparison between them.
>
> Originally I was transferring files between two XP machines over a gigabit
> network. I attempted all possible combinations of drive mapping with no
> effect. Occasionally a recopy *would* match, but often I got no improvement.
>
> I am now transferring the files directly on the target machine, by attaching
> the source hard drive to a spare SATA connection, with the same results. But
> if I come back to it a day or so later, it may suddenly copy and compare just
> fine.
>
> The original configuration was XP-SP2 to XP-MCE-SP2. I'm now only on the MCE
> machine, though I have installed SP3 as well as all current critical updates.
> It is an Intel Core-2 Quad Q6600 with 4GB of RAM. I am running AVG v9 and
> ZoneAlarm v7, and am using Beyond Compare 3 to verify the file transfers.
> Sometimes the comparison fails almost immediately, other times near the end
> of the file.
>
> I've also run Spybot and several other anti-malware programs with no hits,
> as well as memtest86 with no failures.
>
> This is a relatively young machine; it was built a couple years ago but gets
> fairly little use, mainly for bulk storage.
>
> If anyone has any ideas or knows how I can fix this problem I would be most
> grateful. It's been a constant annoyance and I can't find anything that would
> explain it. At this point I'm out of ideas, other than junking it and
> starting from scratch with new components.
>
> Any help would be greatly appreciated.
>
> Thanks!

Nvidia chipset ?

Paul

"Paul" wrote:
>
> Nvidia chipset ?
>
> Paul
> .


No, an Intel P35 chipset. ("P35 Express" according to the book, with an ICH9
southbridge.)

It's a Gigabyte P35-DS3L motherboard, rev 2.0, with version F6 BIOS.
(Graphics: Nvidia 8600GT 256MB PCIe.)

I know there is newer BIOS available for the board (F9) but I'm reluctant to
take that step other than as a last resort. (Maybe I'm there?)

Jason

On 6/11/2010 3:13 PM, J wrote:
> "Paul" wrote:
>>
>> Nvidia chipset ?
>>
>> Paul
>> .
>
>
> No, an Intel P35 chipset. ("P35 Express" according to the book, with an ICH9
> southbridge.)
>
> It's a Gigabyte P35-DS3L motherboard, rev 2.0, with version F6 BIOS.
> (Graphics: Nvidia 8600GT 256MB PCIe.)
>
> I know there is newer BIOS available for the board (F9) but I'm reluctant to
> take that step other than as a last resort. (Maybe I'm there?)
>
> Jason

A painful alternative might be to zip the file you want to copy/move, do
the copy/move on the zip file, then unzip the file at the destination
drive.

J wrote:
> "Paul" wrote:
>> Nvidia chipset ?
>>
>> Paul
>> .
>
>
> No, an Intel P35 chipset. ("P35 Express" according to the book, with an ICH9
> southbridge.)
>
> It's a Gigabyte P35-DS3L motherboard, rev 2.0, with version F6 BIOS.
> (Graphics: Nvidia 8600GT 256MB PCIe.)
>
> I know there is newer BIOS available for the board (F9) but I'm reluctant to
> take that step other than as a last resort. (Maybe I'm there?)
>
> Jason
>

I would try:

1) memtest86+ from memtest.org . You want it to be error free, for two test passes.
Memtest86+ is self booting, and the Windows OS is not present while it is testing.
It comes pretty close to testing all the RAM (might miss about 1MB worth, reserved
by the BIOS). With some care, you could theoretically rotate RAM sticks, such
that all the RAM is tested. but it probably isn't worth the extra effort.
It's not like the reserved RAM plays a part in your symptoms.

The download files are about half-way down the web page.

2) Run Prime95 while in Windows. That program cannot test the memory space used
by the Windows OS, but it does a more thorough job of testing memory elsewhere.
On my 2GB machine, Prime95 will test about 1600MB. It uses all compute cores at
the same time, with a thread per virtual or physical core.

It does not print memory addresses when errors are found. It can report
whether a math calculation it is doing, has an error or not. It knows
what the right answer is. If a thread stops testing, then you know
your computer has some small problem and the compute core isn't bulletproof.
On an overclocked computer, I've had this test fail in as little as 2 seconds.

http://www.mersenne.org/freesoft/

You want to use the "Stress Test" option. You don't have to "Join GIMPS"
to do that.

If those tests are coming up clean, then based on your symptoms, my next test
would be to replace the SATA cable on the drive you're reading from. It could
be that there are data transmission errors on the cable itself. As I understand
it, a CRC check is done on the cable, but that only reduces the frequency of
errors getting through. It was never intended to make flaky cables, new again :-)

You can also try a different SATA port on the motherboard, for the drive being copied.

If a new cable makes no difference, the next suspect would be the controller
board on the drive itself. Test the drive, using a completely different
computer, and that may tell you the drive is having a problem.

The power cable feeding the drive, has +12V and +5V on it. There may be
further regulator devices on the drive controller board, to power
the logic on the controller board. It would probably take a pretty serious
noise problem on the supply rails, to upset the controller logic enough
to cause errors like that. And if the DC voltage values dip a bit, the
drive will actually spin down and spin up again, and the noise from
that happening, tells you there is too much voltage drop on the power
cable. But right now, I don't see a reason to think the power supply
in the affected computer, is playing a part in it. I'd sooner suspect
a bad data cable.

Paul

"Paul" wrote:
>
> I would try:
>
> 1) memtest86+ from memtest.org . You want it to be error free, for two test passes.
>
> 2) Run Prime95 while in Windows.


I'll see if I can mount these drives in my other machine, just to rule out
any cabling or board problems. My only current insight in that area is that
this has affected multiple target drives, so I tend to think the cables are
probably okay. That still leaves the SATA controller, etc., so it's still
worth a try.

I've run memtest86+ once, with no errors, although I only ran the one pass.
I'll let it run longer (overnight) and see if anything happens.

I let Prime95 run for ~30 minutes, before stopping it because things were
getting too warm for my comfort. (No errors.)

That prompted me to try a few more things, though. From the repeated
copying/comparing over the weekend I've started to notice one consistent
thing: if a given file fails to match, even after repeated re-copy attempts,
I'll try that same file again *first thing* the following day after power on
and it tends to work.

Which makes me wonder if I might have a cooling/airflow problem...

I'm doing some experimentation now, tracking temperature numbers in various
modes, under normal operation and then with the case open, with extra fans
blowing in from outside, etc., to see if I can notice any improvement. I
don't *think* the temperatures I see are any concern, though the CPU does
tend to run a few degrees hotter than my other desktop with nearly identical
configuration. (Same CPUs.) Right now I'm seeing idle CPU temperatures in the
38-40C range with Gigabyte's hardware monitoring tool, and ~50C or so with
CoreTemp. The comparisons kick it up a few degrees, but not too much. Those
numbers seem fine (I think) but I'm also concerned that the cramped case
could be restricting airflow to only certain areas. Maybe I'm chasing the
wrong thing, I don't know... I'll have more to go on in a day or two when
I've run the case with some additional outside ventilation.

I appreciate all your help so far, Paul. Thanks!

Jason

J wrote:
> "Paul" wrote:
>> I would try:
>>
>> 1) memtest86+ from memtest.org . You want it to be error free, for two test passes.
>>
>> 2) Run Prime95 while in Windows.
>
>
> I'll see if I can mount these drives in my other machine, just to rule out
> any cabling or board problems. My only current insight in that area is that
> this has affected multiple target drives, so I tend to think the cables are
> probably okay. That still leaves the SATA controller, etc., so it's still
> worth a try.
>
> I've run memtest86+ once, with no errors, although I only ran the one pass.
> I'll let it run longer (overnight) and see if anything happens.
>
> I let Prime95 run for ~30 minutes, before stopping it because things were
> getting too warm for my comfort. (No errors.)
>
> That prompted me to try a few more things, though. From the repeated
> copying/comparing over the weekend I've started to notice one consistent
> thing: if a given file fails to match, even after repeated re-copy attempts,
> I'll try that same file again *first thing* the following day after power on
> and it tends to work.
>
> Which makes me wonder if I might have a cooling/airflow problem...
>
> I'm doing some experimentation now, tracking temperature numbers in various
> modes, under normal operation and then with the case open, with extra fans
> blowing in from outside, etc., to see if I can notice any improvement. I
> don't *think* the temperatures I see are any concern, though the CPU does
> tend to run a few degrees hotter than my other desktop with nearly identical
> configuration. (Same CPUs.) Right now I'm seeing idle CPU temperatures in the
> 38-40C range with Gigabyte's hardware monitoring tool, and ~50C or so with
> CoreTemp. The comparisons kick it up a few degrees, but not too much. Those
> numbers seem fine (I think) but I'm also concerned that the cramped case
> could be restricting airflow to only certain areas. Maybe I'm chasing the
> wrong thing, I don't know... I'll have more to go on in a day or two when
> I've run the case with some additional outside ventilation.
>
> I appreciate all your help so far, Paul. Thanks!
>
> Jason

It could be a chipset temperature issue then. Check to see if the heatsinks
for the Northbridge and Southbridge are secure. The Southbridge would be
the one to affect SATA transfers. But it would have to get pretty hot
for that to happen.

Some manufacturers don't do a good job with the thermal paste between
the provided heatsink and the chipset chips. If the heatsink is riveted in
place, it may be hard to disassemble it and have a look. Before trying that,
see if you can find an example on the Internet, of a disassembly of the
thing. Some small outfits, sell chipset water blocks for water cooling
loops, and may show pictures of how to install something like that on
the motherboard. That would give you some idea how hard it is to take
apart. The thermal paste is necessary, as otherwise, the tiny air
gap between the chip and the heatsink, functions as an insulator, and
a high chip temperature is the result. Thermal pads can be used
to bridge the gap, while hobbyists use paste as the solution.

Some chips run cool enough, they need no heatsink. The Southbridge on
my previous motherboard had no heatsink, and had two SATA ports. A previous
P4 S478 motherboard had no heatsink and it also had two SATA ports. Never
a bit of trouble with either of them, in terms of corruption. The chip
was only lukewarm when you placed a finger tip on it.

Another factor that can affect a chipset, is the provided core or I/O voltage.
These aren't necessarily monitored by the hardware monitor chip, so it's not
like you can check and get a readout on them. Sometimes the BIOS will
have "boost" settings and the like for them. (Vnb, Vsb, or the like).
So that is another outside possibility, too low voltage somewhere
preventing an interface from working error free.

I checked one of my older motherboards, and was shocked how precise
the measured value was. The chip needed 1.2V and the regulator
was delivering 1.200V. No room for complaint there. That kind of
thing doesn't happen that often (perfection). I made the measurement in
that case, with a multimeter. An article on the web, showed where to
probe with the multimeter to get a reading. (A "volt mod" article.)

I'd really prefer that all the critical voltages were monitored, but
I don't think too many people would pay for that option :-)

Paul