Ftp-WG: RE: MFXX questions

Robert,

>     Date:        Sun, 8 Feb 2004 06:53:16
>     From:        Wolfgang Zekoll <[email protected]>
>     Message-ID:  <[email protected]>
>
>   | So it would be possible to set the modification time of a directory with
>   | MFMT but not to query it with MDTM because MDTM excludes directories?
>
>Note that MDTM doesn't "exclude directories", it says that the
>behaviour there is undefined.   That's because different real
>filesystems implement directories in vastly different ways, and
>there is/was no desire to constrain them to necessarily have the
>concept of modification time for a directory, or force one on top
>of the particular server's filesystem.

As David pointed already out, your draft mentions "files" as MDTM 
parameters (section 3).  This is followed by some reasoning with the REST 
command.  But now that I read your draft again (more detailed) I see that 
section 3.1 states

    The "pathname" specifies an object in the NVFS which may
    be the object of a RETR command.

while section 3.2 uses the term "entity".

To make things even more worrying in the examples (section 3.4) I find

    C> MDTM D
    S> 550 D is not retrievable

where "D" is a directory.


>On the other hand, I'd expect the typical unix server's MDTM
>implementation to return the standard unix st_mtime for a directory
>when queried (that's permissible as undefined behaviour).   It
>simply isn't worth the bother to specifically check for the name
>being a directory, and exclude it.

This is one way to see it.  I'll explain you my point of view (coming from 
a real-life programming experience).

Once I decided to write an FTP syncer program.  Ok, what do I have to 
do?  The program has to automatically identify the files on the remote 
filesystem (1), get their modification times (2) do some magic and so on 
(this in not important for my example).  Part (1) is the interesting 
thing.  As far as I know there is no FTP command that tells the client if a 
remote object is a file or directory or whatever (I don't now if MLSD/MLST 
is already common practice).  Then how can I solve task (1)?  Parsing 
directory listings?  Then I recognized that MDTM is my friend.  I have to 
do it anyway for step (2) but since it's only defined on files (and in 
contrast to MLSX it is common practice) I get error responses for every 
non-file on which I try MDTM.  If something which is not a file is really a 
directory is then later checked with a CWD and ... yes I have I want.  I 
did it by reading the MLST draft and, to be honest, I can't see my mistake.

Yes, I recognize that on the server side the additional check if the MDTM 
parameter is a file or not.  But it's only a "stat(filename, &sbuf); if 
(S_ISREG(sbuf.st_mode) ..." and the command combination "TYPE A; SIZE 
some.file" implies more additional work.  And on the other hand, the 
additional MDTM check gives the "isfile-function" as side effect.

Please notice that the reason why I'm doing this discussion (and why I want 
to continue asking question which might bring you or others to a "Oh no 
Wolfgang, not again!") is that things should be defined as exact as 
possible.  As soon as your draft becomes an RFC it's "the 
law".  Implementors will read and rely on it (this is what RFCs are about, 
isn't it?) and unclear things may then become the programmer's "nightmare".

Coming back to MDTM.  In this special case I obviously have a preference 
how it should work.  But anyway, if you would like to define it different, 
then please do it.  Then it's clear which I find better that an uncertain 
specification which might be this or that way.

Regards

Wolfgang Zekoll