Ftp-WG: MFXX questions

David,

after having read the MFXX-draft I started to implement the features 
mentioned there into my own server.  This brought me some some questions.

1. mlst-16 states that the MDTM command is only defined on files, not on 
non-files like directories.  What about MFMT and MFF?  Sometimes the draft 
mentions "file" and sometimes "object in the NVFS", see e.g. section 4.1.

2. Your draft shows (allows?) only the modification of the traditional UNIX 
mode bits, what about the sticky-bit set?

3. I can imagine situations where I don't want remote users to set the 
file's execution bit for uploaded files, even if changing permissions in 
general is allowed.  Such a server receives then a "MFF UNIX.mode=775 
some.file" which is not allowed or, depending on the point of view, not 
supported.  It can now be argued that

   (A) the client's permissions are not enough for the operation which 
results in "550 no access",

   (B) the MFF command is not implemented for this particular argument: 
"504 not implemented for this parameter".

On the other hand, the "no-x-bit" configuration could be seen as some kind 
of "missing granularity" (as it could happen for timestamps) which whould 
then return a

   (C) "213 UNIX.mode=664 some.file"

showing the client the file's real mode after the operation.

Please take these as "questions only", I have no preferences for their 
answers.  It's just that, since we are
discussing this draft, it should perhaps be defined in some way.

Regarding the current modification/creation time discussion, (3C) could be 
also interesting.  As said above, (3C) is already in effect for the MFMT 
and MFCT commands.  But time resolution is mentioned only as one 
example.  Another example could be the OS's limitation that creation time 
can never be newer than a file modification time.  Generalizing such 
OS-dependent cases, the meaning of the 213 response code would become 
something like

    Even if the client receives a 213 response it MUST|SHOULD parse
    the return value given in the response to see if this is (or
    comes near to) what the client wants.

This is not very difficult since the server's response lists the file's 
real attributes (or facts) in the same format as they were requested by the 
client.

But to make the create/modify time thing even more difficult, the question 
if such things are allowed or not, could be filesystem- and not 
OS-dependent (as the time granularity already is: even a Linux system 
doesn't have time resolution down to a second on a real FAT 
filesystem).  So depending on the FTP server's file space (the filesystem 
mounts) operations might work or fail to some degree.  And in the case of 
the MFMT time resolution even a partial failure could (has to be) good 
enough for the client.  So what I'm suggesting here is

   C> MFF Create=20040204105005;Modify=20030926053600; some.file
   S> 213 Create=20030926053600;Modify=20030926053600; some.file

in case the server is not able to set a file's creation time after the 
modification time.  It's now left to the client if this is ok or 
not.  Perhaps a new response code should be defined:

    219 approximate operation: the operation might not have been
        carried out to the client's full satisfaction, the client
        should examine the values listed in the response.


Regards

Wolfgang Zekoll


P.S.: Anyway, now that I'm thinking about it, why should an FTP draft/RFC 
define that a file's creation time is always newer than it's modification 
time?  Even if there are OSes or filesystems that could (thinking of Alun's 
archive example: must or simply does) allow this.  I see this as OS or 
client business, but not as something for an FTP specification.