Xref: utzoo comp.mail.misc:5526 comp.mail.uucp:6635 news.admin:14557
Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!think.com!zaphod.mps.ohio-state.edu!swrinde!elroy.jpl.nasa.gov!decwrl!deccrl!news.crl.dec.com!nntpd.lkg.dec.com!netrix.nac.dec.com!lan_csse
From: lan_csse@netrix.nac.dec.com (CSSE LAN Test Account)
Newsgroups: comp.mail.misc,comp.mail.uucp,news.admin
Subject: Re: BITFTP grief!
Message-ID: <22813@shlump.lkg.dec.com>
Date: 21 May 91 19:36:33 GMT
References: <1991May16.224338.286@crom2.uucp> <1991May17.200736.8137@uu.psi.com> <1991May18.173513.3472@chinet.chi.il.us>
Sender: news@shlump.lkg.dec.com
Followup-To: comp.mail.misc
Distribution: na
Organization: Digital Equipment
Lines: 19

In article <1991May18.173513.3472@chinet.chi.il.us> les@chinet.chi.il.us (Leslie Mikesell) writes:
>
>I'd guess that most FTP users just want the files delivered and don't
>really care about the vehicle.  In fact, given a choice, most people
>would probably prefer uucp's automatic queuing mechanism if the remote
>site can't be reached on the first attempt.

Ummm...UUCP over TCP has been in existence for years; quite a lot of
vendors supply it.  See if your library has uucpd in it; you might also
check your /etc/services or /etc/inetd.conf files for its name.  If it
exists on your system, it is a whole lot nicer than ftp. It retries if
the call doesn't go through; it does proper error checking and doesn't
hand you garbaged files; it runs easily from a script; you don't have 
to do it twice because you forgot to say "binary" the first time, and 
all those good things.  Plus, when I've done timing tests, it has often
run 3-4 time faster than ftp for big files.

If the BSD crowd didn't have such a bad case of NIHitis, we'd all have
it by now...