Ftp-WG: NLST vs MLSD

Alun Jones <[email protected]>; Tue, 15 Oct 2002 13:49:10 -0500:

: At 09:04 AM 10/15/2002, Frank da Cruz wrote:
: >This is what bothers me.  Of course what you say is true, but I don't 
: >think it's a good idea to ignore implementation, existing practice, and 
: >widespread human behavior when modifying a key Internet protocol, if the 
: >modifications can affect all that.
: 
: To an extent.  MLST / MLSD was specifically supposed to ignore 
: implementation, and existing practice, because what is there at present
: is wildly unreliable.
:
From a theoretical standpoint, perhaps.  But people have been using
"mget <wildcard>" since time immemorial.  As far as I know, they are not
complaining.  It does not seem to be a problem in search of a solution
(and "if it's not broken...")

: How many versions of "ls -l" are there?
:
Personally, I would never use LIST as a basis for MGET.  I would never
even dream of parsing host-dependent directory listings.  I would rather
use NLST to get the list of names, and then get whatever info about each
file I could from the server by sending SIZE, MDTM, etc.  But that is so
gross that MLSD is far more attractive for this purpose.

: That was what MLST and MLSD were supposed to replace - LIST, not NLST...
:
It would be silly to say MLSD, when available, can't replace NLST.  If it's
there, it will be used.  Again, I agree MLSD is a fine LIST replacement,
but (and this time let me set this off for emphasis)...:

  --> MLSD is the only way to accomplish recursive MGET <---

: Apparently, there is already implementation of wildcards in MLSD on two 
: servers, and at least one client implementation - the question becomes 
: what, if anything, should be done about that?
:
I think we should consider MLSD already specified except for some details,
like the repertoire of facts and the ordering of the list.  No wildcards, no
filenames; the argument can be empty, or a directory name.  (But you might
want to say a bit more about exactly what format the directory name be in --
anything accepted by the host?  TVFS?  Relative but not absolute?... Can I
send "MLSD somedisk:[dir1.dir2.dir3]" to a VMS server?)

: Sadly, I don't have access at present to a server that implements 
: wildcards in MLSD...
:
There's a publicly accessible one at ftp.ipswitch.com (Robert says they
will be fixing it to comply with the draft, but the last time I looked a
few days ago, it still interpreted wildcards).

: >... Either the FTP client knows the file system syntax of the server
: >host or it doesn't.  In common practice, most clients simply assume
: >the server to be Unix, which is no basis for an open protocol.  If it
: >doesn't know the host's syntax, it can't decompose strings like
: >"[.blah]*.jpg" into CWD and NLST commands (or whatever).
: 
: Without TVFS, if a client user types "MGET foo", the client must "NLST 
: foo", and then RETR everything that it sees in response.
:
Whoa!  In other words you want to say that MLSD "MUST NOT" be used to
implement MGET.  See what I said about that just above, especially the
emphasized part.

: There's almost certainly room for a specification that says "this command 
: takes a specification that refers to one or more files or directories, and 
: lists the matching items in the following format".  MLSD isn't it - so 
: perhaps you'd like to write MLSW?
: 
I'd *like* to :-)  And I'd also like to write MLSR and MLSX.  In other words
all four combinations of who-interprets-wildcards versus whether-to-recurse.

I'd also be willing write a proposal for a standard wildcard syntax if
nobody else wants to take it on.

I'd also like to keep my job, and those of my group.  At the moment this is
enough of an issue that I can't commit to doing anything useful within a
specific time frame, as I normally would do.  In any case, I would like to
see at least some allusions to these issues in the draft so implementors
have some background, guidance, and perhaps an inkling of "as-yet unresolved
issues".

- Frank