Re: A future for the SSH File Transfer Protocol?

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

> > I would actually like to eliminate the long listing format (on a per
> > file basis, I think it adds several hundred percent overhead... on a
> > directory with several hundred files in it, over a slow link, this
> > is a not insignificant overhead.)
> 
> Hmm, hadn't thought of that. And compression will only cut it down
> by so much...
> 
> > But to do so, we need to provide a way for the client to map uid/gid
> > to names.
> 
> ... which would be much more bandwidth-efficient because you only
> need do the mapping once for each uid mentioned, and in the average
> directory listing there are many more files than uids. Nice idea.
> 
> (On the other hand, waiting for the file data to be returned and
> then looking up the uids will cost you another round trip. If your
> link is high-bandwidth but high-latency, this approach might lose!)

True -- on the other hand, you needn't wait until
the directory enumeration is complete to begin
issuing requests to resolve UIDs.  

Alternatively, we could automatically include UID
resolution information as part of the NAMES packet,
avoiding the round trip.  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.

I've also considered a mechanism for the server
to communicate what information is cheaply available
and what information is expensive.  When using
NTFS, for example, security information is costly
to look up (looking up owner / group for each file
can slow down the file list significantly.)

> > I'd be tempted to suggest that UIDs be defined as
> >     string identifier
> > which would be an opaque data structure to the client.
> 
> But suitable for showing to the user, presumably? The ghastly WinNT
> security IDs wouldn't be something the average user wanted to see
> polluting their file listing :-)

True -- they are pretty ugly.

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.

Most unix servers would probably put
the four byte uid in it.

- Joseph