Path: utzoo!attcan!uunet!zaphod.mps.ohio-state.edu!usc!apple!olivea!orc!bu.edu!dartvax!news
From: Jim.Matthews@dartmouth.edu (Jim Matthews)
Newsgroups: comp.sys.mac.programmer
Subject: Re: More questions about ftp.apple.com
Message-ID: <25418@dartvax.Dartmouth.EDU>
Date: 30 Oct 90 14:16:36 GMT
References: <1990Oct29.224857.3293@midway.uchicago.edu>
Sender: news@dartvax.Dartmouth.EDU
Reply-To: Jim.Matthews@dartmouth.edu (Jim Matthews)
Organization: Dartmouth Software Development
Lines: 30

>His theory is that ftp.apple.com is not issuing CRLF pairs, but merely LF's. 
>This would probably work fine on a unix machine, but since gsbacd runs under
>VMS, it needs a CRLF pair to look correctly.

This problem springs from an ambiguity in RFC-959, the document that
specifies the FTP protocol.  The description of the NLST command makes
it seem as if the output of that command can be LF-terminated (instead
of CRLF-terminated, which all other output is).  Jon Postel (the author
of the RFC) has assured me that he did not intend that interpretation,
but the latest ftp server for Berkeley Unix follows it so we're stuck.

There are a couple avenues of action.  Apple could fix the server on
ftp.apple.com -- the line in question is in send_file_list(), where

                        fprintf(dout, "%s\n", dirname);

should be changed to

                        fprintf(dout, "%s\r\n", dirname);

Alternatively, you can use an FTP client that handles LF-terminated lines
(Unix FTP clients, HyperFTP, and NRC's MacFTP included).  Other FTP clients
may provide an alternative file list command (on Unix it's called "dir").
These commands will typically use a different underlying FTP command, and
thereby evade the bug.

Jim Matthews
Dartmouth Software Development

Disclaimer: I wrote MacFTP (but I didn't choose its name!).--