Normally the server responds with a mark using code 150. It then stops accepting new connections, attempts to send the contents of the directory over the data connection, and closes the data connection. Finally it
The server may reject the LIST or NLST request (with code 450 or 550) without first responding with a mark. In this case the server does not touch the data connection.
The NLST format consists of a sequence of abbreviated pathnames. Each pathname is terminated by \015\012, without regard to the current binary flag. If an abbreviated pathname starts with a slash, it represents the pathname obtained by replacing each \000 by \012. If an abbreviated pathname does not start with a slash, it represents the pathname obtained by concatenating
The LIST format varies widely from server to server. The most common format is /bin/ls format, which is difficult to parse with even moderate reliability. This poses a serious problem for clients that need more information than names.
I designed a much simpler format, EPLF, to help clean up the LIST-parsing mess. I recommend that all clients learn how to parse EPLF now. Voyager 3, Lynx 2.6, Mirror 2.9, EMirror 2.1, Fetch 3.5, gFTP 2.0.0, lftp 2.2.0, Pavuk 0.9pl18, ftpcopy, yafc 0.5.2, and Squid 2.3 already understand EPLF.
Once enough clients understand EPLF, servers will obtain better results from EPLF than from /bin/ls. In the meantime, /bin/ls is the best choice for most servers, despite its complexity and unreliability. (My FTP servers, which are designed primarily as web servers, already use EPLF.)
If the file is a regular file, the server provides information about that file, in the same format as a single directory entry. However, if the file is a directory, most servers will provide the contents of the directory, rather than information about the directory. If the client says NLST x, for example, and the response is x\015\012, then x could be a directory containing one file x, or it could be a regular file; the client can't tell. This inconsistency makes LIST and NLST parameters useless for most applications.
I recommend that servers always respond to a nonempty LIST parameter with information about the file, whether the file is a regular file or a directory; this is helpful for some types of indexing clients. I also recommend that servers reject NLST for regular files, and always respond to NLST with directory contents.
Beware that some servers use abbreviated names relative to the current name prefix, instead of the specified directory. I recommend against this behavior.
Traditional UNIX FTP servers also allow the LIST parameter to specify options for the UNIX /bin/ls program. For example, the parameter -t *.c produces a list of .c files, sorted in decreasing order of modification time.
High-quality clients do not attempt to use these features. File selection and sorting are user-interface features that can and should be handled by the client.