Ftp-WG: NLST vs MLSD

At 04:46 PM 10/8/2002, Frank Da Cruz wrote:
> > Apparently two other implementors added functionality that matched your
> > assumption.  Tell me - what do they do when you provide a wildcard that
> > produces results in more than one directory?  What do they list as cdir,
> > pdir, etc?  Can you predict this and rely on the answer?
>
>I doubt it!  As is clearly evident in the real world; specs are one thing,
>implementations another.  Since software development is uncontrolled, the
>only way to write a client that "just works" these days is to experiment
>with every existing server, catalog its quirks, and program around them.

Does each MLSD output for a wildcard spec even produce a 'cdir' 
type?  After all, the wild card isn't going to match a directory, usually, 
yet 7.3.1 of the MLST draft notes that an MLSD response MAY include one or 
more "cdir" type entries, probably because the authors anticipated that 
MLSD's argument would always be a directory that would be listed in that 
'cdir' entry.  "MLSD *.txt" could produce a line that's of 'cdir' type, and 
whose name definitely doesn't match "*.txt".

In the instance that an FTP server allows "MLSD */*.txt", it may even be 
useful to define that a 'cdir' entry should be listed prior to the files 
that match the wildcard spec in its directory.  So that if "*/*.txt" 
matches "a/1.txt", "a/2.txt" and "b/3.txt", you'd have a 'cdir' line that 
specified where 'a' is, followed by listings for "1.txt" and "2.txt", then 
a 'cdir' line for 'b', and a listing for "3.txt".

This goes against the note in 7.3.1 that the 'cdir' entry can occur 
anywhere in the MLSD output, because it would require that the 'cdir' line 
precede all matched elements in that directory.  Would it be worth 
specifying that all 'cdir' output lines must precede other lines relevant 
to that directory?

Here's another thought - what should MLSD do if given a wildcard that 
expands into several names, some of which are directories, others of which 
are files?  Should it list the details of the directories, or the contents 
of those directories?

We either need to specify these sorts of answers, or require that MLSD not 
be used with wildcards.  As you point out, it's too important to rely on 
people fudging it through by successively refining implementations.  It 
needs to be specified this time.

>In any case, my concern is that the new spec conflicts with existing
>practice.  For decades it has been possible for FTP clients to execute
>commands like:
>
>   mget pics/mae-west-*.jpg
>
>or even:
>
>   mget pics*/mae-west-*.jpg
>
>or:
>
>   mget pics/*/mae-west-*.jpg
>
>and get at least a semi-expected result.  This is about to change.

Hardly - NLST isn't going to go away.  It is still expected that NLST will 
be used for MGET.  What you're hoping to do is to _use_ MLSD to get facts 
about those files before transferring them, so that you don't have to do a 
SIZE, MDTM, etc, for each file that you transfer (you could just do an 
MLST, but I can see why you'd like an MLSD with wildcards).

>That's a topic for another day.  For now, there is no standard wildcard
>format, not even within one platform (with a few exceptions).  In Unix, for
>example, every program that expands wildcards does it its own way, either
>with its own custom code, or by calling some nonstandard library or other.

Actually, to judge from the recent problems with "../*/../*" overloads, 
they mostly use glob() from libc.

Alun.
~~~~

--
Texas Imperial Software   | Try WFTPD, the Windows FTP Server. Find us at
1602 Harvest Moon Place   | http://www.wftpd.com or email [email protected]
Cedar Park TX 78613-1419  | VISA/MC accepted.  NT-based sites, be sure to
Fax/Voice +1(512)258-9858 | read details of WFTPD Pro for NT.