Re: filexfer-07

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

Damien Miller wrote:
> With all this talk of adding yet more complexity to sftp/filexfer, I
> have to ask: what is the purpose?
>
> If people want nfs-like functionality in filexfer, then they should just
> specify a subsystem for using NFS over ssh. If filexfer is supposed to
> be simple and lightweight, then the boat has already been missed.

I believe it is still simpler and lighter weight than NFS;
in particular, filexfer excels in the same area that SSH
does: ad-hoc secure networks (or in this case ad-hoc secure
file-sharing.)

Adding NFS to the mix, at least in my opinion, makes it a lot
less ad-hoc in nature.

> Sure, much of the functionality mentioned in the draft is optional, but
> there is a cost to implementors in implementing fallbacks, etc.

Well, if you don't use any optional functionality, you don't need to
implement any fallbacks.

Take for example the locking functionality that has just been discussed;
if you don't ever request any locks, mandatory or advisory, you never
even need to worry about whether the server supports them or not.  No
fallback behavior needed.

> If an
> implementation needs multiple revisions of the draft (all do), then the
> cost is much higher.

The current draft allows you to skip implementating intermediate
versions.  (You have to implement at least version three so extensions
work.)

> Because of this, we (OpenSSH) don't have any plans to implement filexfer
>  > 03. The two or three things that 03 doesn't do that our users ask for
> can easily be done through the extension mechanism.

That would be a shame (both for us who still have to interoperate with
openssh, and for you customers), but I don't expect I'll change your mind.

I guess I understand.  To be honest, 03 supported unix secure file 
transfers pretty well.

It isn't a problem to generate the long listings under unix.
And as long as you don't get to wild in the variations, you
don't care that clients are parsing the string to get the
data that isn't in the attributes.

You don't really have need of most of the new attribute fields,
because unix doesn't support them.

The extra open control doesn't buy you anything, because unix
doesn't really support any of it anyway, and the original open
was modelled after the unix open semantics.

Mode bits express the access control on the file.

And so on.

On the other hand, on windows, we do have real problems, even
with plain-old ftp applications.

For example, we have problems with customers wanting to be able
to control the locking mode.  Under windows, opening files for
exclusive access is customary; have the server do so is what
customers expect in most cases.  But in some cases, for example,
when reading a active log file, customers want an exception to
that rule.

Customers doing a listing expect to see create time in the
listing, not ctime.

uid/gid is meaningless-- windows uses a variables sized structure
to express this information.

If a customer wants information about the files access control,
it can't be expressed as mode bits.

In most cases, the added complexities of the draft are similar
in nature-- they support operating systems that aren't unix in
nature while striving to enable unix platforms to continue
to have complete coverage and pay the minimal price in mandatory
complexity.

There are, admittedly, some new features in the draft do exist
solely to support file-sharing better... but, they aren't the
majority of the complexity.

Thanks,

Joseph