Ftp-WG: Re: comments on the MLST draft

    Date:        Mon, 29 Apr 2002 05:39:17 -0500
    From:        "Gregory A Lundberg" <[email protected]>
    Message-ID:  <[email protected]>

  | On SIZE and MDTM being optional: I don't think they add anything.  MLSx has
  | the info; newer implementations should use MLSx and forget SIZE and MDTM.

MDTM doesn't add much, though it can be easier to fetch and parse, but the
doc does already recommend using MLST to get the same value MDTM returns.
The SIZE cmd and fact return different things though, they're not 
interchangable.

  | I didn't look too closely at the facts for MLSx, but I assume the size fact
  | there is intended to be the actual, stored, size and not the on-the-fly
  | size.  If not, it'll suffer the same problems as SIZE.

The size fact is "an approximation to the size of the file" (or words like
that), and yes, it's intended that whatever the filesystem reports as the
file size can be used (if that's a number in blocks that you then multiply
by the block size to get an approximation, and then find out the last block
wasn't completely filled later, that's fine -- the unix st_size is definitely
fine).  transfer modes are irrelevant.   This is the one that clients should
use when they want the size to display a progress bar, or similar.  But it
is useless for restart.

  | To be BRUTALLY honest, I wish SIZE had never been added.  The "error on
  | conversion" solution is the only way I've come up with which maintains the
  | command as a cheap way to get the file's size without having to read through
  | LIST output, and stop the DoS complaints.

You can certainly do that, I think the spec makes it OK to refuse to
calculate the size of a file that you don't like - set a conf file option,
files bigger than N and SIZE doesn't work (perhaps except in image mode).

  | On why I say REST can appear anywhere: What I was trying to describe was the
  | way existing clients misuse the command in an attempt to see if it _might_
  | work today.  Yes, 959 says it must be immediately followed with a transfer
  | command.  But clients send it at the top of the session, when they're doing
  | SYST and such, and it's typically a command or two away from the data
  | transfer.

Yes, it often is, but I don't think we ought to encourage that.
In practice, lots of commands are pretty obviously going to have no
effect, but I wouldn't like to constrain implementations too much.
The doc is (I think) fairly clear that it is pretty undefined to do
REST other than just before a transfer.

  | On the stuff you're leaving for later:

Yes, of course.

kre