Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!att!tut.cis.ohio-state.edu!ucbvax!bloom-beacon!eru!hagbard!sunic!ericom!eos.ericsson.se!etxtomp
From: etxtomp@eos.ericsson.se (Tommy Petersson)
Newsgroups: comp.sys.amiga
Subject: Re: FTP Servers
Message-ID: <1990Dec28.131408.5402@ericsson.se>
Date: 28 Dec 90 13:14:08 GMT
References: <1033.27783F09@weyr.FIDONET.ORG> <1990Dec26.172922.17717@ericsson.se> <5944@orchid3.UUCP>
Sender: news@ericsson.se
Reply-To: etxtomp@eos.ericsson.se
Organization: Ericsson Telecom AB
Lines: 60

In article <5944@orchid3.UUCP> king@motcid.UUCP (Steven King) writes:
>In article <1990Dec26.172922.17717@ericsson.se> etxtomp@eos.ericsson.se writes:
>>Having no access to ftp, I use bitftp@pucc.princeton.edu to do the ftp for
>>me, from ux1 and abcdf20, specifying BINARY. I get the file UUencoded by
>>email and UUdecode it (I have tried both on a SparcStation and on my Amiga).
>>The files are transferred from Sparc to MS-DOS diskettes using mtools, which
>>has binary transfer as default. From MS-DOS to Amiga I use DOS-2-DOS, which
>>also has binary transfer as default.
>>
>>All files are corrupted, but not totally screwed up. If I have UUdecoded
>>a Zoo archive and does zoo -l archive, it lists 2 or 3 files from the
>>archive before complaining about corrupt file.
>
>I use Bitftp all the time, and haven't found any problems so far.  I
>suspect you're not stripping the headers off the messages before you
>uudecode them.  Uudecode is a rather dumb program.  There's almost no
>error checking done whatsoever.  Bitftp splits large files into
>multiple segments.  If you just cat the segments together and then uudecode
>the large file, UUDECODE WILL TREAT THE MAIL HEADERS AS DATA AND DECODE
>THEM!  Naturally this will mess up the files.  You've got to make sure
>you strip out everything that's NOT uuencoded text.  Anything between
>the "begin" and "end" lines is fair game to be decoded.
>
>Good luck!
>

No, that's not the problem. I have sent so many files using UUencode/decode
before, so it's not any simple mistakes like that. However, I've now tried
with Unix lharc on a large file on Sun, and it seems OK. I haven't
bothered to move it to my Amiga, since lharc.zoo came corrupted...

Our UUdecode on Sun isn't that stupid, if I try and just UUdecode the
catenated file, it complains. The UUencode program at pucc is a bit sloppy,
though. It only puts a begin line at the top of the first part, and an
end at the bottom of the last part.

So current status:
BITFTP: 8 files received, 4 corrupt, 4 seems OK on Sun (lharced)
MAIL:  10 files received, 1 corrupt, 6 OK, 3 lharced seems OK on Sun

It's not so clear-cut any more...

I've got several email's (and postings) with help. It seems like several
of the chains in the link works OK most of the time, but may fail. If
there is such a long chain as I use, almost every time there may be a
new (small but fatal) error. Well, now that it seems like I've gotten
files from bitftp that are not corrupted, things look a little better.
If only I will be able to get lharc and a better UUdecode for my Amiga
that's not corrupted...

I got a KillChip utility, but it crashes the machine. Can anyone
please send that or a similar program to me (again)... And/or tell
me at which jumper I should solder a hardware switch...

I thank everyone for the help I received, and hope the problem was
more like temporary hickups in an involved machine. I'll be back with
more problems next week! (wonder if I should choose WordSync or HAM-E...)

Tommy Petersson
etxtomp@eos.ericsson.se