Commands and files
List files and metadata
Compare human-oriented LIST output with NLST names and standardized MLSD facts.
8 minute lesson
LIST asks for a directory listing, but its text format was never standardized well enough for reliable machine parsing. NLST returns names with less detail.
MLSD, defined later, returns standardized facts such as type, size, and modification time. A capable automated client should prefer MLSD when the server advertises it with FEAT.
Every listing still uses a data connection. A successful login followed by a hanging listing is therefore usually a data-channel problem, not an authentication problem.
Machine-readable facts look like this:
type=file;size=4812;modify=20260730101522; report.csv
type=dir;modify=20260729120000; archiveMLSD returns a directory over the data connection. MLST path can describe one object in a control reply. Servers advertise supported commands and facts through FEAT.
Treat modification time as metadata, not identity. Clocks, upload tools, and server policy can preserve or rewrite it. Size plus time still cannot prove that two files have equal content.
If only LIST is available, use a mature client parser and expect server-specific formats. Do not split on spaces and assume the final token is always a filename.
Capture FEAT, then request one listing. Record whether the client chose MLSD, NLST, or LIST, and explain how it parsed a filename containing spaces.
Lesson completed