Ftp-WG: nlst or mlsd via mget

    Date:        Thu, 3 Oct 2002 09:51:22 -0500
    From:        Pat LaVarre <[email protected]>
    Message-ID:  <[email protected]>

  | Interesting, thank you.  I see an argument that MLSD
  | is unusable for people, in part because it lacks
  | wildcard support, so to retain the command-line
  | usability of NLST we need to establish an MGET that
  | may be NLST or MLSD, depending.

Personally, I think he's gone overboard on options (but then again,
kermit was always the ultimate in absolute flexibility, able to
do just about anything, almost any conceivable way).

The WG discussed wildcarding long long long ago, and decided that it
belongs in the client.

Current uses of wildcards in FTP depend upon the implementation of the
original unix server (which simply ran a shell to run the ls command,
passing through whatever arg NLST or LIST was sent - hence the ability
to send "LIST -lt" not find out about a file called "-lt" but instead
get a listing of the current directory sorted by modify time - and if the
arg happened to be expanded by the shell, then that's what happened).

None of this stuff is in any way standard, nor is it documented anywhere,
and IMNSHO, should never be, it is an utter croc of ...

NLST isn't even intended to be able to return data on normal files,

	The pathname should specify a
        directory or other system-specific file group descriptor;

only directories (or other "file containers" for systems that have
other kinds of filesystems, like "mini-disks").

It is quite clear from 959 that the intent is that the client do a
NLST of a directory, get the results, and use those to select files
to obtain for a "multiple get" or similar command ...   You're not
supposed to send "NLST m*" and then do a RETR on ever file name
returned.    Unix has contributed a lot to the internet, but its
mangling of the FTP protocol isn't one of its brighter lights.

The only issue Frank raises that is really relevant, is whether or not
recursive listings should be implemented via a command, rather than
requiring the client to do lots of MLSD commands, a new one for each
directory.

I don't think there was ever a WG position on that (that I remember
anyway), beyond "not just yet please".  That is, were someone to
actually do the work of defining the format for a recursive listing
response (something that can be properly parsed at the receiver),
I don't expect it would get too many objections.

On the other hand, implementing this at the client really isn't hard,
and really doesn't need a new open file (file descriptor) for every
directory encountered (meaning that there's a limit on the size, or
depth, of the recursion imposed by the number of file descriptors
available to the client implementation).   That's just a cheap simple
implementation technique, but others (such as doing breadth first
recursion, instead of depth first) work just as well, and aren't
hard to implement.

kre