Ftp-WG: draft-somers-ftp-mfxx-01

On Fri, 6 Feb 2004 09:14:19 , you wrote:

>> 1) Dave, what MUST servers do when asked to set a modification date whic=
h
>> is earlier than the creation date?
>>
>> Reply with an Error Code and do nothing?
>> Automatically set the Creation date equal to the new Modification date?
>
> How about crash and burn? - just kidding!
>
> I'm not sure whether attempting to set the modification date prior to the
> creation date is an error. Sure, it may be silly (or just plain stupid), =
but
> some filing systems allow this condition to happen (I think Windows NTFS
> allows it).
>
> How about this:
>
> If MFF is not supported, the client-PI SHOULD issue MFCT (if supported)
> before MFMT. This is to avoid the possible situation where the client-PI
> could set the modification date to a date before the existing creation da=
te,
> which MAY be prohibited by the NVFS. However, it MAY be possible for a
> client to attempt to set the modification time prior to the creation time=
;
> this situation may be nonsensical, it may happen, and it is RECOMMENDED t=
hat
> it not be considered an error by the server-PI.***
>
> *** My feeling is that this is only an issue for Windows users where the
> file system has the concept of create and modify facts. Unix/Posix system=
s
> only have modify, so the create fact will never be able to be modified
> because MFCT will not be implemented, and MFF will not support the Create
> fact. I could be wrong. Comments/Corrections welcome!

If it is true that the create time-val can sometimes be later/greater than
the modify time-val, then perhaps something different should be said at
7.5.4 of http://www.ietf.org/internet-drafts/draft-ietf-ftpext-mlst-16.txt
which now states: "About all that can be said about the value returned [by
a query of creation fact] is that it can never indicate a later time than
the modify fact."; indeed it was that comment, and the potential here for
an inconsistency with it, which prompted my question.

>> 2) Is a change to the Creation date a Modification?  Right now there is
>> vagueness as to what changes constitute "Modification" and so call for
>> changes of Modification dates.  Would it be appropriate to give guidance
>> on what changes SHOULD call for changes to the Modification date, or is
>> that to remain outside the scope of this work?
>
> OK. I'm thinking of adding the following:
>
> - All facts are to be considered autonomous, and modifying any facts MUST
> not cause the server-PI to update the modify fact (unless impossible to
> avoid due to the operating environment). The modify fact MUST only be
> modified by either MFMT or through the Modify fact to MFF.
>
> - Given the choice, client-PIs SHOULD use MFF in preference to issuing MF=
CT
> then MFMT.

Tony