Re: A future for the SSH File Transfer Protocol?

[Simon Tatham <anakin%pobox.com@localhost>]

"Joseph Galbraith" <galb-list%vandyke.com@localhost> wrote:

> Or perhaps there would be an additional flag to the READDIR command
> specifying whether UID resolution information should be
> automatically sent.
> 
> Perhaps a more general mechanism for the client to tell the server
> what information is important would be appropriate.

Ooh. Yes, this _does_ sound good; it also solves your other problem
(once you've included the user database information to make the long
name fields unnecessary, how do you arrange that the long name
fields don't get sent anyway and waste all that effort?).

Perhaps another extended data type, parallel to ATTRS but used for
requests rather than responses? It might look something like this:

  uint32   flags
  uint32   extended_count present only if flag
                          SSH_FILEXFER_ATTR_EXTENDED
  string   extended_type
  ...      more extended_type strings
           so that number of strings equals extended_count

So you can set all the same flags that would be set in the returned
ATTRS, and request particular types of extended data as well (to
preserve extensibility).

Except that of course that doesn't _include_ the long name field,
because it's not part of ATTRS. Bah. Time for an unprincipled hack
to the above, or back to the drawing board?

> However, the thing that is suitable for display is the resolved
> username.  I would actually suggets that the identifier string is a
> binary blob -- it is only suitable for sending back to the server in
> order to manipulate the security of a file.

Oh, I see. Fair enough. So if I wanted to assign ownership of a file
to Fred, I'd do a getuserbyname("fred"), and the binary blob that
came back would be suitable for using in FXP_(F)SETSTAT.

Cheers,
Simon
-- 
Simon Tatham         "I thought I'd put my foot so far into my mouth I
<anakin%pobox.com@localhost>    wouldn't be able to sit down without standing up."