Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!cs.utexas.edu!rice!uupsi!cci632!sjo From: sjo@cci632.UUCP (Steve Owens) Newsgroups: comp.binaries.ibm.pc.d Subject: Re: Problem retrieving archive programs via FTP Keywords: archive FTP Kermit Message-ID: <50675@cci632.UUCP> Date: 14 Feb 91 14:38:54 GMT References: <1991Feb13.042158.25755@csuvax1.csu.murdoch.edu.au> <1991Feb13.152910.16132@linus.mitre.org> Distribution: usa Organization: Computer Consoles Inc. an STC Company, Rochester, NY Lines: 30 In article <1991Feb13.152910.16132@linus.mitre.org>, dhf@linus.mitre.org (David H. Friedman) writes: > > I was doing essentially the same thing, ftp'ing files from wustl and > kermit'ing to a PC for copy to a diskette. In my case, .ZIP files wouldn't > unZIP properly on the PC. I finally compared hex dumps on the PC and on my > UNIX box, and found that the Kermit-to-Kermit transfer was introducing extra > characters - it looked like every 0Ah was being changed to 0Dh 0Ah, i.e., > every CR was being changed to LF-CR even though the transfer mode was > supposedly BINARY! I couldn't find which Kermit parameter, if any, enabled > or disabled this translation. (I was using MS-Kermit 2.31 on the PC.) The On the Unix box where I work, there is a parameter called "file mode," or something like that, that is set for either "converted" or "literal". I thought this was the CR-LF to CR conversion parameter, but I've never tried it. > fix I had to use is to UUENCODE the files on the UNIX box, Kermit them to > the PC, and UUDECODE them back to binary. If you need UUDECODE for the PC, > it's in the starter kit that's periodically posted to comp.binaries.ibm.pc. This, to me, would be the preferred way of doing it, because you don't have to worry about conversions or file types (except for transfering the uudecode bootstrap program, but even that's typically not a problem.) If you don't have the uudecode from the starter kit, get it. It will save you a lot of hassles in the long run. > dhf@linus.mitre.org sjo@op632.cci.com