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 that can be provided in the result from
the new MLST command is recommended as a superior alternative.
When attempting to restart a RETRieve, the user-FTP can use the MDTM
command or the "modify" fact to check 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.
Because the user- and server-FTPs' clocks are not necessarily
synchronised, user-FTPs intending to use this method should usually
obtain the modification time of the file from the server before the
initial RETRieval, and compare that with the modification time before
a RESTart. If they differ, the files may have changed, and RESTart
would be inadvisable. Where this is not possible, the user-FTP
should make sure to allow for possible clock skew when comparing
times.
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 that may be the object
of a RETR command. Attempts to query the modification time of files
that exist but are unable to be retrieved may generate an error-
response, or can result in a positive response carrying a time-val
with an unspecified value, the choice being made by the server-PI.
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
Note that when the 213 response is issued, that is, when there is no
error, the format MUST be exactly as specified. Multi-line responses
are not permitted.
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], a server-FTP 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, but 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, a directory D,
two files with names that end with the string "ile6", 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 20
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".
