Ftp-WG: NLST vs MLSD

At 01:26 PM 10/13/2002, Frank da Cruz wrote:
>That the MLSD spec does not permit filenames or mixtures of paths and
>filenames in its argument; thus the user is not allowed to send this
>argument to the server in an MLSD command.  Note that I don't advocate
>changing MLSD in this respect.  But from the user's point of view, a
>command that once worked will no longer work and this will cause confusion,

Why?  You've given no indication as to why MGET - the "command that once 
worked" should use anything other than NLST.  Hence, MGET will work exactly 
the same way it does now.

>An operation that was possible
>before is suddenly impossible.

Only if you insist that MGET must use MLSD.  Why not stick with NLST, as 
you are today?  MLST / MLSD replaces only one (inappropriate) use of LIST, 
not NLST.

>If a text file is sent in binary mode to a radically different platform,
>the result is garbage (and vice-versa, of course).

Incorrect.  If a text file is sent in binary mode, the result may be a file 
where the line-ends are not in the local format, but the file is far from 
being garbage.  Tools exist even on DOS - very simple tools - to convert 
"Mac" and "Unix" style line ends to "DOS" style, and vice-versa.

>We're going in circles.  The topic here was recursive downloads.

No.  The topic was wildcards in MLSD.  There are wildcards that will 
produce matches that list the contents of one or more directories; there 
are wildcards that match some files and some directories.  If MLSD is to 
match wildcards, it must be done reliably, and in a manner that can be 
replicated by client and server.

>: Why a fact for MODE?
>:
>Why not?  If FTP has a MODE command with a selection of values, and if,
>in a certain setting, the value makes a difference, then it would be useful
>for the server to suggest the appropriate MODE for a given file (if the
>server knows it) so the user doesn't receive garbage.

Because every mode can be used to transfer any file.  Hence, MODE is 
entirely the choice of the client.

>Years ago I, too, thought inspection was gross.  Then I tried it.  In Unix
>and Windows, the effect of looking at (say) the first 48K of a file is
>barely measurable (unless it's on a floppy disk or something).

Are you the same Frank that was proposing the server manage a million files 
in a directory?

>That's fine.  I would like to be sure the current draft does not close any
>doors on the issues raised here, and that some of its ambiguities are
>cleared up (e.g. the format of dir, cdir, and pdir types) before it
>advances, and maybe a few more file facts included.  Perhaps the TYPE fact
>should become mandatory; what's the point of listing a file if the client
>can't tell from the list whether it's a file or directory?

The point of making the TYPE fact (or any fact) optional, surely, is so 
that it doesn't add to the length of a listing if the client doesn't care 
to know it.  The client, not the server, chooses which facts to ask for in 
its OPTS command.

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.