Re: SFTP owner, group and mode flags...

["Joseph Galbraith" <galb-list%vandyke.com@localhost>]

> > * In order to reduce overhead of readdir and
> >   stat operations, which will increase with
> >   the above, we add a parameter to the opendir
> >   and stat protocols to allow the client to
> >   specify what attributes it is interested in.
> 
> I don't know whether this is necessary. If the longname is eliminated, 
> then I don't think the replies will be very large.

Sorry, I should have tied this better with
the last point (which I've moved below):

> > * We allow a server to advertise what attributes
> >   it can provide and what attributes it can provide
> >   efficiently, but require servers to tolerantly
> >   ignore requests for attributes it can't provide
> >   and require that clients be prepared to not receive
> >   attributes that the server has advertised.
> > 
> >   For example, under NT, we would advertise that we
> >   can provide User, Group and ACL information, but
> >   that they are expensive.
> 
> What do you mean by expensive? I am a little ambivalent against 
> advertising capabilities, especially ones relating to whether certain
> operations are "expensive" for the host OS. 

Here's what I'm thinking.  It is expensive for me to
get user, group and security information.  I.e., returning
user, group and security information slows a directory listing
down by more than an order of magnitude.

So, right now, since I have no clue whether the client really
wants the information, I never return it.

If, on the other hand, I could both tell the client
that it was relatively expensive to ask for that
information, and know that the client really wanted
to use the data, I could return the information.

The client could make an informed decesion about
whether it wanted the security information or
not, knowing that it is expensive for my server
to acquire that information.

And my server would know that the client really
intended to do something with the information
if it asked for it.

Even if we didn't allow the server to advertise,
it would still be useful to know what the client
wanted.

> > * Change the mode field to a type field, which indicates
> >   the type of the file, and make it a byte field.
> 
> Can you be more specific? 

Sorry, I've had a couple of questions on this;
I definitely wasn't clear (and may have used
the wrong term, too.)

There are two peices of information encoded into
the permissions field of that sftp attribute
structure.

* The file type
* The access control information (permissions)

I was proposing that we seperate out the file
type into a BYTE field, and do away with the
permissions field in favor of ACLs.

However, I don't feel strongly about doing away
with the permissions field.  In fact, after thinking
about it, I realized that it might not be so easy to
encode things like the sticky bit in an ACL, so there
may be good reason not to.

But, I do feel strongly about splitting the two
pieces of information into seperate fields.

In particular, my NT server can't send valid information
for the permissions field, but can send valid type
information.  So right now, it lies about the permissions.

- Joseph