Hello,
I ran into a problem today which I have run into before. It usually takes
me a MANY attempts at solving a problem like this before I run out of ideas.
But this time, I'm about to my end!
It has to do with FTP downloads. Maybe some of you have seen it before.
It is a read error of some kind that happens in the middle of the download
of a _particular_ file. The behaviour IS NOT sporadic. It happens in the
exact same place in the downloading file--every single time. In fact, I can
even "tac" the file into a _reverse_ copy of itself, using shell commands in a
shell on the host server, and then try to download it backwards! Even then--it
bombs at the exact same place in the file. Right in the middle... I'm
using wu-ftpd servers on both of the test machines (I've tried "getting" and
"putting"--no difference). And I've use both regular "ftp" and "NcFTP" clients
to attempt the download, both getting and putting.
Here's another interesting thing. I had almost abandoned hope of getting
this 7MB file downloaded when my curiousity got the best of me. I figured
that if the problem was reproduceable, at the same place in the file every
time, then I should be able to extract that "bad" chunk. I did just that.
I used head, tail, cat, and tac to incrementally chop the file into pieces
all around the spot that seemed bad. I successfully downloaded the front of
the file and the back of the file (each part being about 3.5MB). Those
downloads were flawless. That left only a 1K chunk in the middle, the culprit
chunk, yet to download. I didn't try to whittle that down any smaller. By
this
time, I figured that if I pulled that 1K out of the 7MB, I'd already spent too
too much time on it!
That 1K file still wouldn't download! It wouldn't even _start_
downloading it. So what I figure is that I've managed to provide evidence
to support that the problem is NOT any of the following...
1. FTP client
2. direction of transfer (i.e. get vs. put)
3. size of the file (i.e. choking it with too much data--bandwidth)
And I may have provided supporting evidence that suggests that there is
actually a bad piece of the file. But here's the thing that gets me.
Doesn't the ftp server just deliver whatatever data I request? It doesn't
_really_ care what's in there, right? (aside from setting it for ascii or
binary) How can the file actually be bad? And if it was "bad," how the
heck would the ftp server know it?
To explain my next point, let me just a little history. I first tried
to download the file from it's primary FTP site across the Internet onto my
Linux PC at home, over a 28.8 modem. The download bombed at that same
location that I mentioned before. So, I thought it was a fluke and tried
it again. Same thing. So I tried several of the mirror sites. Each in
turn gave the same error and at (roughly) the same place in the file
each time. Well, by that time I was sick of doing all of that trial and
error over a time-consuming 28.8 link, so I got into a shell account of
mine that sits on a T1 connection. I downloaded the culprit file from
more than one of the same sites that I just mentioned. It was a flawless
download--took only a few minutes. So that makes me think, "whatever the
problem is, the file IS downloadable, or I wouldn't have downloaded it
over a T1." [By the way, the mirror that I downloaded from was using
wu-ftp for a server, just like the other machines that I'd tested]
Grand Finale... Why can I download the file over a T1 and not a modem,
even if I download it in pieces. And if it was something quirky with my
modem, then why does it happen in exactly the same place in the file on
each attempt? If the file _is_ actually bad, what sort of magic is in there
in a T1 connection, which is NOT in modem, that overlooks the file's flaw and
downloads anyway?
I mentioned earlier that this has happened to me before. I was trying to
download one of the versions of the gcc source tarball from ftp.gnu.org
(and it's mirrors. And that time, it didn't even work over a T1--not even
from a shell on MIT's Athena network!) This time the culprit file is
one of the NetBSD distribution files called comp.tgz found under
/pub/NetBSD/NetBSD-1.3.2/i386/binary/sets on several servers including
ftp.netbsd.org
ftp.cs.umn.edu
ftp.eecs.umich.edu
ftp.iastate.edu
Well, that's my story... Anybody have any ideas?
======================== Mike Wilkerson ==========================
"You cannot go on 'seeing through' things forever. The whole point
of seeing through something is to see something through it."
C.S. Lewis, "The Abolition of Man"
PGP Public Key: http://www.talleytech.com/~mwilkers/mypubkey.asc
==================== [EMAIL PROTECTED] =====================
--
PLEASE read the Red Hat FAQ, Tips, Errata and the MAILING LIST ARCHIVES!
http://www.redhat.com/RedHat-FAQ /RedHat-Errata /RedHat-Tips /mailing-lists
To unsubscribe: mail [EMAIL PROTECTED] with
"unsubscribe" as the Subject.
