Re: SFTP File open modes

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

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?

The semantics you're describing here are a lot more restrictive even
than <stdio.h> mandates for text files; in <stdio.h>, you may not be
allowed to know what a file-position variable actually looks like,
but you're at least allowed to read up to a certain point in the
file, save the file position, then return to the same position later
and continue reading from there.

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.)

I think this is a low-quality solution and if I had a vote to cast
I'd vote against it.

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.)

This solution doesn't destroy any statelessness properties of SFTP,
and permits (AFAICS) all the sequences of operations permitted by
<stdio.h> on text files.

(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?)

Cheers,
Simon
-- 
Simon Tatham         "The distinction between the enlightened and the
<anakin%pobox.com@localhost>    terminally confused is only apparent to the latter."