Problem w/ Firewire External HDs [was Re: Problem unzipping files on external HD]

[ggull]

This thread started on microsoft.public.windowsxp.general, when I had
problems unzipping gigabyte size archives downloaded directly to an external
firewire hard drive. Pegasus suggested I compare a file downloaded to an
internal HD with that same file copied to the external HD using

fc /b c:\big.zip f:\big.zip

and indeed that found differences, and also noted that the copy was shorter
than the original (though right-click > properties shows they are the same
"size"). Pegasus suggested I try a hardware group, so here I am.

I think the problem is more with the Firewire hw/sw on my computer than the
hard drives per se, but I hope you can give me some ideas or point me to a
more relevant group.

I have available multiple computers, external drives, and cables, and ran a
bunch of tests that seem to show it is a problem with Firewire only, on the
one computer only.
The computer in question is a Gateway 503GR, two internal SATA HDs, DVD, CD
drives, nothing else connected to the ports except a USB printer (lj 1012).
WinXP HE SP2, all relevant updates.

Here are the test -- skip to the end at any time --

Test 1) External HD #1 -- 160 GB Acomdata Dual Firewire/USB
FAILS
Firewire, cable 1, rear port on computer. Internal drive J:, external F:
Copy J:\SCRATCH\big.zip to F:\SCRATCH\big.zip
fc /b j:\.scratch\big.zip f:\scratch\big.zip
FC seems to be finding clumps of difference ... i.e. outputs a bunch of
lines, pauses, outputs more, pauses, etc. Maybe 5 or 10 clumps, dozens or
at most hundreds of lines each.
Total number of lines longer than buffer available in command prompt, but
here are last few

21343FFB: 00 15
21343FFC: B2 B7
21343FFD: FF 41
21343FFE: FF 8F
21343FFF: FF DD
FC: J:\SCRATCH\big.zip longer than F:\SCRATCH\BIG.ZIP

Test 2) Change cable and port.
FAILS
HD #1
Firewire, Cable 2, front port
Copy...
fc ...
Similar differences, but with different detail. This time no "longer than"
notice.

Test 3) Use USB connection: Note this is still same external HD: OK
HD # 1
USB, USB Cable 1, front USB port on computer.
File Compare output:

Comparing files J:\SCRATCH\big.zip and F:\SCRATCH\BIG.ZIP
FC: no differences encountered

Test 4) Try a different Firewire HD:
FAILS
HD # 2, 250 GB Acomdata Firewire -- Drive M:
Firewire, cable 1, rear port on computer
Copy...
fc ...
Similar behavior, several patches of difference.

Test 5) Transfer the file big.zip to a second computer using DVD-RW.
OK
This is a WIndows Me machine with Firewire but only USB1 Copied to HD#2
and ran FC -- no differences found.

If it matters the file system on the Gateway (XP) is NTFS, and on the Me
machine and the external drives, FAT32.

SO ...

1) Am I correct in thinking this indicates a problem with Firewire on the
Gateway?

2) How can I narrow it down further (eg hardware / software) and then fix
it?

3) Lastly, why doesn't the system notice the bad write when copying to the
external HD? I thought that data files (as opposed to audio CD files) had a
bunch of built-in error detection and correction.

 

[Jonny]

Ummm. Firewire cable length. 4 or 6 wire or combination used in this
cable. Size of file copied. SP2? If so, are you forcing 400 or 800?
Onboard Firewire or card? Firewire chipmaker? Smaller copies work? If so,
at what point does size make copy fail?

 

[ggull]

Thanks for some good questions. Replies interspersed:

Ummm. Firewire cable length.

6 foot / 2 meter

4 or 6 wire or combination used in this cable.

Looks to be 6 contacts in the connectors. I haven't seen any other kind of
firewire cable or port, these are very standard, bidirectional, made to
daisy chain (the drives have two ports on each). The cables were provided
by the drive maker.

Size of file copied.

As stated, on the order of a gigabyte. The specific archive I used to test
is 0.83 GB. I had the initial problem (failure to extract) with archives
ranging from about 0.6 or 0.7 to 1.3 or 1.4 GB. (I had downloaded a bunch
before trying to work with them.)

SP2?

As stated, on the computer giving the problem, Win XP Home Edition with
Service Pack 2.
I should have mentioned it's a bit over a year old, i.e. just out of
warranty.

If so, are you forcing 400 or 800?

I'm not sure I understand the question. Are these the two speeds of
Firewire? I'm sure both machines (the one that worked and the one that
didn't) wouldn't have the latest and greatest, nor would the drives support
it.

Onboard Firewire or card? Firewire chipmaker?

Onboard. It's an Intel D915GAV or ...AG board w/ IEE-1394a controller and
three 1394a connectors. The manual doesn't specify any chip manufacturer.

Smaller copies work? If so, at what point does size make copy fail?

OK, I'll run a test.
18 MB file (.shn) -- OK (FC /B finds no differences)
107 MB file (wav) -- OK
297 MB file (.zip) -- 3 patches of difference (from watching results fly
by); original longer than copy.
124 MB file (.zip) -- 1 patch of difference, original longer
Note that "size" of the original and copy (as determined by Properties) is
the same in both cases -- how does that differ from "longer than"?
115 MB file (.zip) -- no differences (i.e. specific bytes) but does note
original longer than copy.
144 MB file (.zip) -- 1 patch of difference, not longer

This raises the question, is it the "zipness"?
I zipped the 107MB wav file (it came out 100MB), and tested that -- OK, no
differences.
Did the same for the 18 MB shn file -- OK.

I started using zip archives because they were the only large files I could
think of. Now I recall I have a couple of larger wav files. Try one of
these:

707 MB file (.wav) -- about 6 patches of difference, not longer

So .. it looks like we're getting about one patch of continguous or close
difference per 100 MB. Watching this zip by it doesn't seem regular. (I
could capture and post or email a complete listing if anyone is interested.)
My hunch is it is random, not some kind of threshold. If I sat down and
did, say, several 50MB files, then I should find a difference in roughly
half of them. But it's a bit late for this evening.


<Snip long original post>

 

[Jonny]

Thanks for some good questions. Replies interspersed:

6 foot / 2 meter

Looks to be 6 contacts in the connectors. I haven't seen any other kind
of firewire cable or port, these are very standard, bidirectional, made to
daisy chain (the drives have two ports on each). The cables were provided
by the drive maker.

As stated, on the order of a gigabyte. The specific archive I used to
test is 0.83 GB. I had the initial problem (failure to extract) with
archives ranging from about 0.6 or 0.7 to 1.3 or 1.4 GB. (I had
downloaded a bunch before trying to work with them.)

As stated, on the computer giving the problem, Win XP Home Edition with
Service Pack 2.
I should have mentioned it's a bit over a year old, i.e. just out of
warranty.

I'm not sure I understand the question. Are these the two speeds of
Firewire? I'm sure both machines (the one that worked and the one that
didn't) wouldn't have the latest and greatest, nor would the drives
support it.

Onboard. It's an Intel D915GAV or ...AG board w/ IEE-1394a controller and
three 1394a connectors. The manual doesn't specify any chip manufacturer.

OK, I'll run a test.
18 MB file (.shn) -- OK (FC /B finds no differences)
107 MB file (wav) -- OK
297 MB file (.zip) -- 3 patches of difference (from watching results fly
by); original longer than copy.
124 MB file (.zip) -- 1 patch of difference, original longer
Note that "size" of the original and copy (as determined by Properties) is
the same in both cases -- how does that differ from "longer than"?
115 MB file (.zip) -- no differences (i.e. specific bytes) but does note
original longer than copy.
144 MB file (.zip) -- 1 patch of difference, not longer

This raises the question, is it the "zipness"?
I zipped the 107MB wav file (it came out 100MB), and tested that -- OK, no
differences.
Did the same for the 18 MB shn file -- OK.

I started using zip archives because they were the only large files I
could think of. Now I recall I have a couple of larger wav files. Try
one of these:

707 MB file (.wav) -- about 6 patches of difference, not longer

So .. it looks like we're getting about one patch of continguous or close
difference per 100 MB. Watching this zip by it doesn't seem regular. (I
could capture and post or email a complete listing if anyone is
interested.) My hunch is it is random, not some kind of threshold. If I
sat down and did, say, several 50MB files, then I should find a
difference in roughly half of them. But it's a bit late for this evening.


<Snip long original post>

100/400/800 speed noted in this KB article specifically for XP SP2 use.
http://support.microsoft.com/kb/885222/en-us

 

[ggull]

100/400/800 speed noted in this KB article specifically for XP SP2 use.
http://support.microsoft.com/kb/885222/en-us

Thanks again, Jonny.
I checked out the KB article, and it doesn't look like it's applying here.

(1) The only symptom the article notes is a slowdown in performance after
adding SP2. The speed of the port is reduced. Nothing about write or
transmission errors. (Maybe I should check to make sure I'm getting all the
speed possible, but that's not the issue here.)

(2) KB: "This problem occurs if you connect a 1394a or 1394b FireWire
device to a 1394b port. This problem occurs because Windows XP SP2 changes
1394b ports to S100 speed when you upgrade." As stated, the motherboard
manual claims the controller and connectors are 1394a, not 1394b. I don't
see how to confirm this from the Device Manager.

(3) And FWIW, the OS came with SP2, it wasn't an upgrade. The KB article
only seems to apply to upgrades, i.e. it's something in the upgrade process
that alters SidSpeed.

Was this what your question about "forcing 400 or 800 " was? I.e., did I go
into the registry and alter the speed, and maybe somehow mess it up? If
that's what you were thinking, I didn't go near this, didn't even know about
the issue.

I'll try to run some further tests .. specifically, copying a bunch of
shorter files over to see if the errors are on some random "per byte" basis,
and also using the USB connection on my dual to verify that it was a bad
write, not some bad transmission while running FC ... but given the info so
far, do you have any ideas what could be causing these errors and what to do
(other than replace the MB)?

 

[Jonny]

Thanks again, Jonny.
I checked out the KB article, and it doesn't look like it's applying here.

(1) The only symptom the article notes is a slowdown in performance after
adding SP2. The speed of the port is reduced. Nothing about write or
transmission errors. (Maybe I should check to make sure I'm getting all
the speed possible, but that's not the issue here.)

(2) KB: "This problem occurs if you connect a 1394a or 1394b FireWire
device to a 1394b port. This problem occurs because Windows XP SP2 changes
1394b ports to S100 speed when you upgrade." As stated, the motherboard
manual claims the controller and connectors are 1394a, not 1394b. I don't
see how to confirm this from the Device Manager.

(3) And FWIW, the OS came with SP2, it wasn't an upgrade. The KB article
only seems to apply to upgrades, i.e. it's something in the upgrade
process that alters SidSpeed.

Was this what your question about "forcing 400 or 800 " was? I.e., did I
go into the registry and alter the speed, and maybe somehow mess it up?
If that's what you were thinking, I didn't go near this, didn't even know
about the issue.

I'll try to run some further tests .. specifically, copying a bunch of
shorter files over to see if the errors are on some random "per byte"
basis, and also using the USB connection on my dual to verify that it was
a bad write, not some bad transmission while running FC ... but given the
info so far, do you have any ideas what could be causing these errors and
what to do (other than replace the MB)?

Some guesses. Firewire cable defective in some manner. Hard drive's
enclosure for firewire interface.
Am using strictly firewire interface, Acomdata enclosure. Onboard firewire
is Texas Instruments chip for firewire (motherboard). Works great in 98SE,
ME, and XP SP1, and now, SP2. You might remake the enclosure's hard drive
partition while connected via firewire, not usb.

 

[ggull]

Thanks for the possibilities you suggest --

Some guesses. Firewire cable defective in some manner.

As stated in original post, my experiments included using two different
cables, resulting in failure with both on the original computer. Using at
least one of these cables and the same drive on a second computer, the copy
was OK.
This seems to eliminate defective cable(s), no?
That's why I did the experiments reported in OP.

Hard drive's enclosure for firewire interface.

Again, experiments already reported seem to eliminate this. I had the
problem for two distinct external drives / enclosures. Both Acomdata, but
different capacities and models. (Three enclosures if you count the
original extraction experience.) Used on a second computer, no problem.

These and other experiments already done and reported are why I felt the
problem probably lies in the Gateway XP computer itself, not the cable or
external drive. Also something more fundamental than a dirty or loose
connector, since I tried all three ports on the Gateway.

Am using strictly firewire interface, Acomdata enclosure. Onboard
firewire is Texas Instruments chip for firewire (motherboard). Works
great in 98SE, ME, and XP SP1, and now, SP2.

An impressive array of upgrades for a single MB . And I'm glad to hear
your Acomdata drive has been running all that while.

I'm just curious -- would you have noticed write errors every 100 MB or so?
Do you use files that large, if it's a threshold thing? Are they something
that might just present a slight glitch (music or photos) instead of
outright croaking?

You might remake the enclosure's hard drive partition while connected via
firewire, not usb.

I'm not familiar with "remake the ... partition". Do you mean to format it?
Makes some kind of sense, but these came pre-formatted, and I'll bet the
format was done before they were put in the enclosures, so I'd think it's a
long shot. But again, this is focusing on the drive, not the onboard
firewire.