Ftp-WG: mdtm and mlsd commands

Wolfgang Zekoll <[email protected]> Tue, 3 Feb 2004 15:53:18
Newsgroups gmane.ietf.ftpext
Message-ID <[email protected]>
Hello,

> >>>
> >>> Anything that does that is broken, it is a query command only.  There are
> >>> no standardised "set attributes" command, for any attributes I'm aware of
> >>> (possibly excluding the name...)
> >>
> >> That's a real shame as it prevents FTP from being used in mirroring.
> >
> >
> > Our FTP server for NetWare supports a site specific command. I think we 
> copied this
> > idea from some other server, but I can't recall, its been 10 years.
> >
> > site chmdtm <filename> <modtime> [<acctime>] -- change 
> modification/access time of
> > file
>
>Sounds fine, but I wonder why the working group is ignoring an absent but
>apparently needed facility which software developers are now programming
>around in a common but, of necessity because of the lack of any standard,
>a non-compliant manner.

although I'm not a member of the working group I'll try to give an 
explanation based on what I know about FTP.

As author of some FTP server software I simply must follow the original 
statement, MDTM is query only.  When I considered to implement MDTM-modify 
for my server I recognized that the guys who introduced MDTM-modify must 
have been UN*X guys.  Why?  How can the sever determine if the MDT; command 
it just got from the client is the query of modify form.  Does the 
timestamp belong to the filename or is it the modify timestamp?  This 
question can only be answered if blanks are excluded from the filename 
character set which is the natural situation for every UN*X admin).  But as 
far as I know the FTP RFCs don't do this, they allow blanks.  As Linux 
admin I can attest that blanks in filenames are bad practice but I also 
know that today's users expect them.

As server administrator I don't think that I would ever allow a remote 
client to modify timestamps of files in the FTP area.  How could I be sure 
that my existing software (backup software, archive indexer etc.) can deal 
with the situation that a newly modified file has a timestamp in the past?

Now for the last point of view, software programmer.  Using MDTM-modify is 
what I call the "easy way", easy to use, moving client problems to the 
server, even if it's non-standard.  The correct, and only sligthly more 
difficult, way would be to use some local book keeping, the client should 
maintain the meta information it needs locally.  You might take a look of

    http://www.awk-scripting.de/cgi-bin/wiki.cgi/scripting/FtpSync

to see an example for this.

But I have a question to the real FTP protocol gurus: Is there a 
recommended way to tell a client that a server does not support MDTM-modify 
but MDTM-query?

Regards

Wolfgang Zekoll