Problem unzipping files on external HD

[ggull]

I've been downloading concert recordings in the form of zipped files, each
zip containing typically 10-20 compressed music files (shn or flac). The
zips are 1 GB, more or less. For example, go to
http://www.archive.org/audio/etree-details-db.php?id=11584
and click on either the "Download Show: Lossless" link at the left, or the
855.5M link at right. This is the 'first' zip on which I did the
experiments below.

I just added another external HD, an Acomdata 250GB, Firewire, pre-formatted
as FAT32. I'm running Win XP HE SP2, but didn't convert to NTFS to maintain
back compatibility with older systems. I checked the external for errors,
including bad sectors, from Properties > Tools > Error Checking before using
it. [I have two internal SATA NTFS HDs and another external USB FAT32 HD
plugged in but not used in this exercise. I have done this same download &
unzip with all of these drives without problems (except some seeming
incomplete downloads).]

I download three zip files, then go to unzip them. First one I try, right
click >extract all, the wizard starts, I hit 'next', 'next' and it chugs for
a minute, opening the output directory. Then it croaks, with a popup:
"Error reading the file" with a big red-filled circle
with white X within it,
and the usual 'OK' button.

Hmmmm .... I delete it and download again, this time with no concurrent
downloads.
Same error when I try to unzip.

Try a second downloaded zip, same thing.

Download the first file to one of my internal HDs -- it extracts just fine,
and the extracted files are all OK (MD5 file integrity signatures are
provided). I compare the two zip files, on the internal and external HDs,
using the right-click properties, and they are the exact same length in
bytes. Now the weird part:

I copy this verified zip file from the internal to external HD, in a
different directory from the first instance, and this copy now refuses to
extract, with the same error.

Further weirdness -- I then tried the third of the original zips I'd
downloaded, and it unzipped successfully.

Any ideas? This has got me stumped, and every hypothesis seems contradicted
by some datum.

Oh yes, in one of the zips that failed to extract, I opened it like a
regular directory and tried to drag copy the files to a separate location /
drive. Most would just fail with no error msg, but a couple would make it
and check out OK.

 

[Guest]

have you tried to add a new folder to your desktop?
(right click add new folder)
drag and drop file with the right mouse button to new folder / extract files
then open from the new folder

 

[ggull]

Thanks for the suggestion. I tried something like that before logging on
this morning.
Remember I had downloaded one of the files (that wouldn't unzip on the
external HD) to an internal HD, direct from the website. In that location
it unzipped OK.
Then I copied (right-click & drag > copy, I think, although between drives
it would be the same just to left click and drag, or is there some subtle
difference?) this working file to the external HD. Here, it gives same
error when I try to extract as the file downloaded directly to external HD.

So this morning I got the idea to now copy this copy back to the internal
HD.
I did so, and this copy of copy of good file fails to extract.
To me, this is an indication that there's some problem with the file once it
gets written to the external HD, not some difficulty with running extract on
that drive.

OK, I think I see the difference. Youre suggesting to extract directly to
the folder on the desktop, not copy and then extract. I just did that, and
get the same error.

When I right click > properties on each of these three copies, they are all
the same size,
855,486,984 bytes.
The "size on disk" varies:
855,425,024 bytes Internal HD, original copy, extracts OK
855,506,944 bytes External HD, first copy, fails.
855,416,832 bytes Internal HD, second copy, fails.
I can see the difference between the original and first copies -- the
internal HD is NTFS, with compression enabled, the esternal is FAT32 without
compression.
But the smaller "size on disk" of the second copy compared to the original
is puzzling, it's on the same disk.

I think a friend has the same external drive; I'll see if I can borrow it
and run a test. Maybe I've got a bum unit, but I'm surprised it give bad
writes without complaining.

have you tried to add a new folder to your desktop?
(right click add new folder)
drag and drop file with the right mouse button to new folder / extract
files
then open from the new folder

I've been downloading concert recordings in the form of zipped files,
each
zip containing typically 10-20 compressed music files (shn or flac). The
zips are 1 GB, more or less. For example, go to
http://www.archive.org/audio/etree-details-db.php?id=11584
and click on either the "Download Show: Lossless" link at the left, or
the
855.5M link at right. This is the 'first' zip on which I did the
experiments below.

I just added another external HD, an Acomdata 250GB, Firewire,
pre-formatted
as FAT32. I'm running Win XP HE SP2, but didn't convert to NTFS to
maintain
back compatibility with older systems. I checked the external for
errors,
including bad sectors, from Properties > Tools > Error Checking before
using
it. [I have two internal SATA NTFS HDs and another external USB FAT32
HD
plugged in but not used in this exercise. I have done this same download
&
unzip with all of these drives without problems (except some seeming
incomplete downloads).]

I download three zip files, then go to unzip them. First one I try,
right
click >extract all, the wizard starts, I hit 'next', 'next' and it chugs
for
a minute, opening the output directory. Then it croaks, with a popup:
"Error reading the file" with a big red-filled
circle
with white X within it,
and the usual 'OK' button.

Hmmmm .... I delete it and download again, this time with no concurrent
downloads.
Same error when I try to unzip.

Try a second downloaded zip, same thing.

Download the first file to one of my internal HDs -- it extracts just
fine,
and the extracted files are all OK (MD5 file integrity signatures are
provided). I compare the two zip files, on the internal and external
HDs,
using the right-click properties, and they are the exact same length in
bytes. Now the weird part:

I copy this verified zip file from the internal to external HD, in a
different directory from the first instance, and this copy now refuses to
extract, with the same error.

Further weirdness -- I then tried the third of the original zips I'd
downloaded, and it unzipped successfully.

Any ideas? This has got me stumped, and every hypothesis seems
contradicted
by some datum.

Oh yes, in one of the zips that failed to extract, I opened it like a
regular directory and tried to drag copy the files to a separate location
/
drive. Most would just fail with no error msg, but a couple would make
it
and check out OK.

 

[ggull]

<snip>

OK, I think I've narrowed it to a problem with my system, either hardware or
software.

Recall I'd been having trouble when downloading gigabyte-size zip archives
downloaded to an external firewire hard drive. I'd run "extract all", and
would get an "Error reading the file" error. If I downloaded to an internal
drive, the extraction went fine. Copy this 'good' zip archive from the
internal to firewire external drive, and it fails again. (Copying it to a
USB external drive results in successful extraction.)

To isolate the problem, I managed to get together two other firewire drives
and another cable. Copying the good archive to each of the three firewire
drives -- failure.
Using either cable -- failure.
Using all three firewire ports (2 front, one rear) -- failure.

I then write the 'good' archive to a DVD, move it to a different computer,
and move over one of the firewire externals. Then copy the good archive to
the external drive. AHA -- it now extracts successfully on the external.
This second computer is running Windows Me.

As far as I can see this implies:

1) there is some difference between Win Me and XP that acounts for the
problem (not likely, I'd imagine), or

2) there is some hardware problem at a level more fundamental than a loose
cable, since it's all three ports, or

3) I have a glitch in the software on the XP machine, most obviously a bad
or corrupted driver.

So, as probably the easiest thing to try, how do I fix the driver?

 

[Pegasus \(MVP\)]

<snip>

OK, I think I've narrowed it to a problem with my system, either hardware or
software.

Recall I'd been having trouble when downloading gigabyte-size zip archives
downloaded to an external firewire hard drive. I'd run "extract all", and
would get an "Error reading the file" error. If I downloaded to an internal
drive, the extraction went fine. Copy this 'good' zip archive from the
internal to firewire external drive, and it fails again. (Copying it to a
USB external drive results in successful extraction.)

To isolate the problem, I managed to get together two other firewire drives
and another cable. Copying the good archive to each of the three firewire
drives -- failure.
Using either cable -- failure.
Using all three firewire ports (2 front, one rear) -- failure.

I then write the 'good' archive to a DVD, move it to a different computer,
and move over one of the firewire externals. Then copy the good archive to
the external drive. AHA -- it now extracts successfully on the external.
This second computer is running Windows Me.

As far as I can see this implies:

1) there is some difference between Win Me and XP that acounts for the
problem (not likely, I'd imagine), or

2) there is some hardware problem at a level more fundamental than a loose
cable, since it's all three ports, or

3) I have a glitch in the software on the XP machine, most obviously a bad
or corrupted driver.

So, as probably the easiest thing to try, how do I fix the driver?

If you suspect a faulty data path then you should compare
your files at a binary level, e.g. like so from a Command
Prompt:

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

where f: is the drive letter for your external drive.

 

[ggull]

If you suspect a faulty data path then you should compare
your files at a binary level, e.g. like so from a Command
Prompt:

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

where f: is the drive letter for your external drive.

Thanks! I'll do that.

I did figure out to uninstall the driver from the device manager and
reinstall it by restarating computer (there were no updates available).
Didn't make any difference. I un/reinstalled the "OHCI Compliant IEEE
1394 host controller". I notice a "SBP2 Compliant IEEE 1394 device" shows
up when the external drive is actually turned on. Is there anything I can
do to make sure that driver is OK? I'm a little leery of uninstalling while
the drive is actually running, and besides it seems to install itself only
when the drive is started.

 

[ggull]

If you suspect a faulty data path then you should compare
your files at a binary level, e.g. like so from a Command
Prompt:

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

where f: is the drive letter for your external drive.

OK, done. It found a long list of what I assume are differences,
<location> <file1 byte> <file2 byte>
longer list than the buffer in command prompt (I scroll up and can't see the
orginal FC command).
It also says that the original (good) zip is longer than the one on the
firewire external.

Here's the last few lines of its output:

21344FF9: FF 2A
21344FFA: FF AA
21344FFB: FF E5
21344FFC: 7B 61
21344FFD: FF 06
21344FFE: FF 82
21344FFF: FF B8
FC: J:\SCRATCH\big.zip longer than F:\SCRATCH\BIG.ZIP

(J is an internal drive, F the external)

If it matters, J is NTFS, F is FAT32.
But I assume we're comparing file content, not storage on disk.

Any idea where to go from here?
btw, THANKS!

 

[ggull]

If you suspect a faulty data path then you should compare
your files at a binary level, e.g. like so from a Command
Prompt:

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

where f: is the drive letter for your external drive.

OK, done. It found a long list of what I assume are differences,
<location> <file1 byte> <file2 byte>
longer list than the buffer in command prompt (I scroll up and can't see the
orginal FC command).
It also says that the original (good) zip is longer than the one on the
firewire external.

Here's the last few lines of its output:

21344FF9: FF 2A
21344FFA: FF AA
21344FFB: FF E5
21344FFC: 7B 61
21344FFD: FF 06
21344FFE: FF 82
21344FFF: FF B8
FC: J:\SCRATCH\big.zip longer than F:\SCRATCH\BIG.ZIP

(J is an internal drive, F the external)

If it matters, J is NTFS, F is FAT32.
But I assume we're comparing file content, not storage on disk.

Any idea where to go from here?
btw, THANKS!

 

[Pegasus \(MVP\)]

OK, done. It found a long list of what I assume are differences,
<location> <file1 byte> <file2 byte>
longer list than the buffer in command prompt (I scroll up and can't see the
orginal FC command).
It also says that the original (good) zip is longer than the one on the
firewire external.

Here's the last few lines of its output:

21344FF9: FF 2A
21344FFA: FF AA
21344FFB: FF E5
21344FFC: 7B 61
21344FFD: FF 06
21344FFE: FF 82
21344FFF: FF B8
FC: J:\SCRATCH\big.zip longer than F:\SCRATCH\BIG.ZIP

(J is an internal drive, F the external)

If it matters, J is NTFS, F is FAT32.
But I assume we're comparing file content, not storage on disk.

Any idea where to go from here?
btw, THANKS!

Your test proves that your problem has nothing to do with
unzipping. It is caused by the files on your external disk not
being true copies of the originals. I suggest you start a new
thread in a hardware group, perhaps cross-posted into this
one, to attract the attention of experts on external Firewire
disk.

 

[ggull]

Your test proves that your problem has nothing to do with
unzipping. It is caused by the files on your external disk not
being true copies of the originals. I suggest you start a new
thread in a hardware group, perhaps cross-posted into this
one, to attract the attention of experts on external Firewire
disk.

OK, I'll do that after I run a few more tests using the File Compare
utility, e.g. using different external drives, ports, cables. Of course
there's always the manufacturer, but (also of course) it's about 2 months
out of warranty.

 

[cquirke (MVP Windows shell/user)]

"ggull" <[email protected]> wrote in message

Recall I'd been having trouble when downloading gigabyte-size zip archives
downloaded to an external firewire hard drive.

How big are these files?

Are they too big for the destination file system, if that is FATxx?

Are they too big for the utility that extracts the contents?

---------- ----- ---- --- -- - - - -

Don't pay malware vendors - boycott Sony

 

[ggull]

How big are these files?

Are they too big for the destination file system, if that is FATxx?

Are they too big for the utility that extracts the contents?

Good questions.

The zip archives range from somewhat under 1 GB (the one I've been using as
a test is about 0.85 GB) to a max of 1.6 GB.

I don't think it's an issue of they're being too large for FAT32 (isn't the
limit there something like 4 GB?) or the built-in XP Extraction Wizard
(right click, extract all). I don't get this problem when using a USB2.0
external HD, also FAT32 (nor on internal NTFS drives, which at least speaks
to the extraction utility as a problem). It seems to be something with the
Firewire connection (see other posts on this thread).

 

[cquirke (MVP Windows shell/user)]

The zip archives range from somewhat under 1 GB (the one I've been using as
a test is about 0.85 GB) to a max of 1.6 GB.

OK. AFAIK FAT32's max size is 4G, whereas some file formats have a
limit of 2G. A factor may be unsigned vs. signed addressing, e.g. if
a limit assumes unsigned addressing but an app traverses the contents
using signed offsets, the app could have a limit half that expected.

Either way. 0.85G should be clear, unless there's an indirect limit
such as "number of files within an archive" or similar.

I don't get this problem when using a USB2.0 external HD, also
FAT32 (nor on internal NTFS drives, which at least speaks
to the extraction utility as a problem). It seems to be something with the
Firewire connection (see other posts on this thread).

OK. That in turn may have to do with chipset and drivers, whether
Windows sees the drive as fixed / removable / valid etc., whether the
file system on the HD has an atypical format (e.g. cluster size that
is not the default for that volume size) etc.

Or there may be hardware-level issues with the Firewire itself. USB
is prone to insufficient power issues; dunno if it applies to
Firewire. All of these hardware, chipset, drivers etc. issues would
be more likely to give intermittent and variable errors and
corruption, rather a 100%-repro that pivots on a set byte limit.

---------- ----- ---- --- -- - - - -

Don't pay malware vendors - boycott Sony

 

[ggull]

"cquirke (MVP Windows shell/user)" wrote...

OK. That in turn may have to do with chipset and drivers, whether
Windows sees the drive as fixed / removable / valid etc., whether the
file system on the HD has an atypical format (e.g. cluster size that
is not the default for that volume size) etc.

Hmmm. It's just possible that Acomdata uses an atypical format -- the three
firewire drives that give the problem are all Acomdata, two different
models. One of them is dual firewire/USB, and I'll test to see if that
works with USB and fails with firewire connection.

Or there may be hardware-level issues with the Firewire itself. USB
is prone to insufficient power issues; dunno if it applies to
Firewire.

If you mean power delivered over the connection, as with laptop-type
external devices, that shouldn't be an issue. The drives in question all
have their own power supply.

All of these hardware, chipset, drivers etc. issues would

be more likely to give intermittent and variable errors and
corruption, rather a 100%-repro that pivots on a set byte limit.

From the extract-all "diagnostic" it seems that the error is "intermittent
and variable" as you describe ... at least the extraction process doesn't
always seem to bomb at the same point.

I'll run a few more tests using the "file compare" diagnostic and report
back, with a cross-post to comp.sys.ibm.pc.hardware.storage (unless you can
suggest a better hardware group).

 

[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.