RFC Errata


Errata Search

 
Source of RFC  
Summary Table Full Records

RFC 3659, "Extensions to FTP", March 2007

Source of RFC: ftpext (app)

Errata ID: 901
Status: Rejected
Type: Technical
Publication Format(s) : TEXT

Reported By: Alfred Hoenes
Date Reported: 2007-04-14
Rejected by: Pete Resnick
Date Rejected: 2011-05-16

Section 7.5.4 says:

   The create fact indicates when a file, or directory, was first
   created.  Exactly what "creation" is for this purpose is not
   specified here, and may vary from server to server.  About all that
   can be said about the value returned is that it can never indicate a
   later time than the modify fact.

It should say:

   The create fact indicates when a file, or directory, was first
   created.  Exactly what "creation" is for this purpose is not
   specified here, and may vary from server to server.

Notes:

It is one of the benefits of 'Create' timestamps for directory
entries that there is *no* enforced relationship between that
timestamp and the 'Modify' timestamp related to the file *content*.

We still support legacy systems from Hewlett-Packard that indeed
maintain three timestamps per directory entry: 'Create', 'Modify',
and 'Access'. The very useful behaviour of the File System and
the proprietary Networking Services is as follows: If you move a
file to another directory or copy it (within a system, or across
the network), the 'Modify' timestamp does not change (since the
file content is unchanged from what it was then), only the 'Create'
timestamp of the new directory entry is set to the current time.
(This means the 'Modify' timestamp behaves like a 'last update'
timestamp embedded in the file content, e.g., in a PDF file.)
In this case, the create fact would have to be *later* than the
modify fact, for RFC 3659. Naturally, if a file was being edited,
the 'Modify' timestamp changes and will then be later than the
'Create' timestamp.
The natural behaviour of a hypothetical FTP client implementing
RFC 3659 in such environment, when performing a 'get' operation,
would be to obtain the modify timestamp of the remote file via
MLSx or MDTM and, after performing the RETR (and, perhaps verifying
the 'atomicity' of the transfer via another MDTM that should deliver
the same response again) setting the 'Modify' timestamp of the local
copy of the file to the moment corresponding to the MDTM result
value (or the modify fact value from the MLSx).
--VERIFIER NOTES--
This is a technical change that may be against the consensus of a WG and therefore is not appropriate for an erratum.

Report New Errata