Copied files do not match originals

[J]

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!

 

[Paul]

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

 

[J]

"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

 

[Mike S]

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.

 

[Paul]

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

 

[J]

"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

 

[Paul]

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