Ftp-WG: RE: MFXX questions

> So it would be possible to set the modification time of a directory with
> MFMT but not to query it with MDTM because MDTM excludes directories?

I think MFMT has been implemented a few times to work with both files and
directories ;-)

It could be argued that on some systems that a directory is just a special
kindof file, so its not really breaking the rules for MFMT to work with
both. YMMV.

I've realized that MFxx is probably a bit misleading in that the 'file' part
of the name should really be 'object'... but I'm not sure whether its worth
changing the name now (to MOxx)... it depends if I'll get lynched by people
who have already implemented MFxx - although a nice backdoor could be to say
that MFxx is an alias for MOxx :-)

> >Let's be clear about this: draft-somers-ftp-mfxx only specifies two facts
> >for use in MFF, 'Create' and 'Modify'. Any others mentioned are purely
> >examples of what could be possible - not what is possible - see section
> >5.2.1.
>
> Well, now that you mention it, yes your draft doesn't deal with
> UNIX modes

Yep.. that is something for another document... especially as the facts
should work with both MFxx and MLSx.

> (just as side-note: setting sticky-bits is possible for normal users).

OK. I'll take your word for it.

> This example was perhaps not exact enough.  I'm talking of an FTP-server
> running on a UNIX box, being able to modify file mode bits.  But the
> administrator decides for some reasons that he does not like remote FTP
> clients to set the x-bit of files, anything else, like e.g. 666,
> is ok for
> files, but not setting any x-bit as in 775, even if the user owns
> the file
> and has all the permissions he or she needs to do it (the same
> chmod would
> succeed if the user would be logged in local with a shell).
>
>
> If the server would deny, I think 504 is more exact, because it's not
> really a permission thing but a set x-bit in the parameter.
>
> But anyway, I prefer variant C.  Why?  In the no-x-bit server setup the
> server's "permission granularity" is artificially degraded by the admin
> while modifying UNIX permissions in general is allowed (that's why the
> server offers UNIX.mode in it's FEAT response).

I think variant C is probably the way to go.

This is very implementation specific, and should be covered by whatever
document details UNIX.xxx facts (hint!).

One solution could be something like this:

UNIX.mode - to set the bits, does best effort (MAY be artificially degraded
by the admin), so client-PI MUST parse the 213 response to determine exactly
what did or did not happen to the bits (requested bits and the response bits
could be different).

UNIX.strictmode - to set the bits, does NOT do best effort, NO artificial
degredation allowed. Returns 550 if the exact bits can not be set/cleared,
otherwise 213 (requested bits and the response bits are identical).

> To be more precise, I suggest that the client parses the 213 server
> response for any of the commands MFMT, MFCT and MFF because the
> server may
> not have exactly done what the client asked for.  The no-x-bit is just
> another example of such a situation.

OK. Again it was implicit in the draft (the response MAY be different from
the request). I'll add that its RECOMMENDED for the client to parse the 213
response. (I think most clients would do that anyway because they cache the
facts).

> The return code 213 is already in use for MDTM and SIZE.  And in these
> contexts the return data is always exact (the modification time of a file
> has an exact value) and the return data is exactly what the client asked
> for (the modification time).  With the MFXX commands is still exact but
> it's value may not be exactly what the client asked for.  Because of this
> difference a new return code could be used to make it clear for
> everyone.  But this is perhaps simply a question of my personal taste.

I don't see a reason to use a response other than 213.

Yes, the response may not be what was requested, but it is exact.

> P.S.: David, you mentioned that someone could write something about UNIX
> permissions and FTP.  If you (or someone else) could point me to
> the "Draft
> Editors Guide and How-To for Beginners" I would consider doing the job.

Separate email sent to you with the details.

Cheers,

David.