RE: SFTP File open modes

[Richard Whalen <Whalenr%process.com@localhost>]

> -----Original Message-----
> From: Simon Tatham [mailto:anakin%pobox.com@localhost]
> Sent: Thursday, March 28, 2002 10:47 AM
> To: ietf-ssh%netbsd.org@localhost
> Subject: Re: SFTP File open modes
> 
> 
> Richard Whalen  <Whalenr%process.com@localhost> wrote:
> > A server implementation that implements the ASCII read option will
> > need to maintain an internal persistent file pointer. When a file is
> > opened in ASCII mode all access must be sequential and the offset in
> > the READ & WRITE operations must be ignored.
> 
> So you're ruling out the possibility of, for example, two
> interleaved sets of read requests both reading the file from the
> beginning? Or a set of requests reading from beginning to end, with
> an extra request in the middle that takes another quick look at the
> very start of the file?
>

You'll have to clarify your question, as you didn't specify whether the
streams are from a single open request or from two open requests.  Read
requests from multiple open requests could proceed in parallel.
 

> 
> Also, you've just broken the stateless nature of SFTP. (Well, not
> _completely_ stateless, since the existence or non-existence of a
> file handle is state, but the absence of a concept of current
> working directory and the absence of file pointers strongly suggest
> that the designers had statelessness in mind as a desirable
> property.) Do you think SFTP should never have attempted to be
> stateless? Or that loss of statelessness is a small price to pay for
> ASCII file transfer, and it's not even worth trying to work out
> whether we can have both? Do you know _why_ SFTP is largely
> stateless? (I don't, and for precisely that reason I'd want to avoid
> breaking its statelessness in case there was a really good reason
> for it I hadn't thought of.)

No, I don't know the reason why SFTP is largely stateless; it is not
explained in the specification.  My guess is that the authors were familiar
with NFS (which is stateless), and created operations that are similar to
that.  The current specification does have the ability to provide general
file access, but is missing a method of transferring (text) files between
different systems.

I don't really think that there are any benefits to SFTP being a stateless
protocol.  Since it runs over a reliable transport requests don't get lost,
and hence, do not have to be repeated (part of the reason that NFS is
stateless).  Memory and computes are cheap these days, so keeping state
around is not a problem.  I'm not saying that stateless protocols are bad,
just that they are not necessarily better than stateful protocols.

The absence of the concept of a current working directory in SFTP would
really be beneficial if there had not been an attempt to define what a file
path looked like.  It would allow the server to do the appropriate things to
combine two parts of a file path and return something that could still be in
a system independent format.


> An example of an alternative solution that doesn't suffer from these
> problems would be to define new message types FXP_TEXT_READ and
> FXP_TEXT_WRITE. These hypothetical messages would work just like
> FXP_READ and FXP_WRITE, but instead of a numeric file offset they
> would take an opaque `file position' type. You'd have some standard
> means of constructing a `file position' type corresponding to the
> very start of a file, and you'd be entitled to re-use a given file
> position as many times as you liked once you'd received it from an
> FXP_TEXT_READ or FXP_TEXT_WRITE call. (These operations would have
> to return the file position after the read/write _as well_ as
> returning the number of bytes read/written and the data.)
> 

The operations that you propose are a viable alternative.

> 
> (Both these solutions assume that it's easy to define a wire format
> for textual data. I'm not sure what such a thing might be. UTF-8
> with \n line endings, perhaps? Or something negotiated between
> client and server?)
> 

A wire format for textual data was defined as far back as RFC 959 (FTP) (and
probably further).  Yes, text has been expanded these days to allow a wider
character set, and some considerations for this should be made.  But the
bulk of the textual data sent these days is done with a character set that
uses an 8 bit unit.

My employer's customers expect SFTP to provide functionality similar to what
is provided by FTP, with the added security of encryption and improved
authentication methods. The protocol that is currently defined is not
capable of providing that functionality.

----------------------
Richard Whalen
Process Software