[prev in list] [next in list] [prev in thread] [next in thread] 

List:       wuftpd-questions
Subject:    Re: MDTM command
From:       "Gregory A Lundberg" <lundberg () vr ! net>
Date:       2001-04-26 20:23:36
[Download RAW message or body]

> I was wondering if it is possible to configure wu-ftpd 2.6.1 to allow
users to
> issue a MDTM command to set the time/datestamp on uploaded files.  Some
FTP
> client software packages automatically do this.  Currently, I only know of
one
> FTP server that allows this (Serv-U Version 2.3c build 12).  Any help
would be
> appreciated.

What is MDTM?  All I can find for it is a reference but no definition in RFC
2389.

Of, there it is in a Draft.  So ...

MDTM is not (yet) part of the FTP, so you'll find very few clients or
servers which support it.  Any which do should be labeled "experimental"
with respect to features such as this.

Happy hacking ...

3. File Modification Time (MDTM)

   The FTP command, MODIFICATION TIME (MDTM), can be used to determine
   when a file in the server NVFS was last modified.  This command has
   existed in many FTP servers for many years, as an adjunct to the REST
   command for STREAM mode, thus is widely available.  However, where
   supported, the "modify" fact which can be provided in the result from
   the new MLST command is recommended as a superior alternative.

   When attempting to restart a RETRieve, if the User-FTP makes use of
   the MDTM command, or "modify" fact, it can check and see if the
   modification time of the source file is more recent than the
   modification time of the partially transferred file.  If it is, then

   most likely the source file has changed and it would be unsafe to
   restart the previously incomplete file transfer.

   When attempting to restart a STORe, the User FTP can use the MDTM
   command to discover the modification time of the partially
   transferred file.  If it is older than the modification time of the
   file that is about to be STORed, then most likely the source file has
   changed and it would be unsafe to restart the file transfer.

   Note that using MLST (described below) where available, can provide
   this information, and much more, thus giving an even better
   indication that a file has changed, and that restarting a transfer
   would not give valid results.

   Note that this is applicable to any RESTart attempt, regardless of
   the mode of the file transfer.

3.1. Syntax

   The syntax for the MDTM command is:

        mdtm          = "MdTm" SP pathname CRLF

   As with all FTP commands, the "MDTM" command label is interpreted in
   a case insensitive manner.

   The "pathname" specifies an object in the NVFS which may be the
   object of a RETR command.  Attempts to query the modification time of
   files that are unable to be retrieved generate undefined responses.

   The server-PI will respond to the MDTM command with a 213 reply
   giving the last modification time of the file whose pathname was
   supplied, or a 550 reply if the file does not exist, the modification
   time is unavailable, or some other error has occurred.

        mdtm-response = "213" SP time-val CRLF /
                        error-response

3.2. Error responses

   Where the command is correctly parsed, but the modification time is
   not available, either because the pathname identifies no existing
   entity, or because the information is not available for the entity
   named, then a 550 reply should be sent.  Where the command cannot be
   correctly parsed, a 500 or 501 reply should be sent, as specified in
   [3].  Various 4xy replies are also possible in appropriate
   circumstances.

3.3. FEAT response for MDTM

   When replying to the FEAT command [6], an FTP server process that
   supports the MDTM command MUST include a line containing the single
   word "MDTM".  This MAY be sent in upper or lower case, or a mixture
   of both (it is case insensitive) but SHOULD be transmitted in upper
   case only.  That is, the response SHOULD be

        C> Feat
        S> 211- <any descriptive text>
        S>  ...
        S>  MDTM
        S>  ...
        S> 211 End

   The ellipses indicate place holders where other features may be
   included, and are not required.  The one space indentation of the
   feature lines is mandatory [6].

3.4. MDTM Examples

   If we assume the existence of three files, A B and C, and a directory
   D, and no other files at all, then the MDTM command may behave as
   indicated.  The "C>" lines are commands from user-PI to server-PI,
   the "S>" lines are server-PI replies.

        C> MDTM A
        S> 213 19980615100045.014
        C> MDTM B
        S> 213 19980615100045.014
        C> MDTM C
        S> 213 19980705132316
        C> MDTM D
        S> 550 D is not retrievable
        C> MDTM E
        S> 550 No file named "E"
        C> mdtm file6
        S> 213 19990929003355
        C> MdTm 19990929043300 File6
        S> 213 19991005213102
        C> MdTm 19990929043300 file6
        S> 550 19990929043300 file6: No such file or directory.

   From that we can conclude that both A and B were last modified at the
   same time (to the nearest millisecond), and that C was modified 21
   days and several hours later.


   The times are in GMT, so file A was modified on the 15th of June,
   1998, at approximately 11am in London (summer time was then in
   effect), or perhaps at 8pm in Melbourne, Australia, or at 6am in New
   York.  All of those represent the same absolute time of course.  The
   location where the file was modified, and consequently the local wall
   clock time at that location, is not available.

   There is no file named "E" in the current directory, but there are
   files named both "file6" and "19990929043300 File6".  The
   modification times of those files were obtained.  There is no file
   named "19990929043300 file6".

[prev in list] [next in list] [prev in thread] [next in thread]