WANCHO@WSMR-SIMTEL20.ARMY.MIL ("Frank J. Wancho") (10/17/89)
Notwithstanding the mandate in RFC 1123, the FTP server should never *assume* a transfer mode that has not been explicitly requested. If the current mode is obviously wrong, such as for directory listings, which are *always* sent in NETASCII mode, the server has no choice except to complain if the current transfer type is not ASCII. If the FTP client is set up for some form of binary mode (type l whatever), and the server sends a directory listing in NETASCII, the resulting display or redirected file will not contain the expected format. Thus, it is up to the client to keep track of the requested file transfer mode and switch temporarily to ASCII mode for directory listings. This discussion came up because a user wanted to use mget. There is a trap in this, even if the directory list is transferred correctly. The user must be certain that all the files are of the same type. For example, an mget should work right now, modulo the filename trimming, for a group of ASCII files. But, mixed file types are a problem, not just with this machine, but between any two machines which do not have the same wordsize or byte order. (I have been toying with the possibility of extending our STAT filename to include bytesize information without breaking TOPS20 FTP clients which depend on the format of the reply. The idea here is that the FTP client would implement a mget to get a list of filenames from the remote, issue a STAT filename prior to each get to parse the reply to set the appropriate transfer type.) Last comment: we have found several FTP clients which try to parse the filename in a get into a local filename, and do it wrong. For example, VAX/VMS TWG ftp will try to parse "get alias:file.type" and complain to the user that "alias:file.type" is a bad (local) filename. The user is confused because it appears that the message came from the FTP server, implying the file does not exist. The workaround is to have the user enclose the remote filename in double quotes and specify a receiving filename. Note that there are two problems: one with the failed parse attempt, and the other with the error message not properly identified as being a local error message. --Frank