Subject: RE: SFTP File open modes

From: Richard Whalen <[email-masked]>
Date: Thu, 28 Mar 2002 09:36:02 -0500

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.

-----Original Message-----
From: Simon Tatham [mailto:[email-masked]]
Sent: Wednesday, March 27, 2002 5:03 PM
To: [email-masked]
Subject: Re: SFTP File open modes

Richard Whalen  <[email-masked]> wrote:
> add the flag SSH_FXF_ASCII to the SSH_FXP_OPEN message.
> When this flag is set, the file will be transferred in system independent
> ASCII text format, if appropriate.
> The system independent format is defined as characters separated by a
> newline character to specify end of line.  The system that is storing the
> file may make any changes necessary to store the text in a manner that is
> compatible with standard methods for that system.  When a file is
> transferred in ASCII mode, the total number of bytes transferred may be
> different from the size provided by the SSH_FXP_xSTAT function.  Ideally,
> the number of bytes transmitted should never be greater.

This seems fine to me as far as it goes, but how do you split the
file into multiple FXP_READs when there's no persistent file pointer
and each FXP_READ must specify a precise file offset where the
previous one left off?
-- 
Simon Tatham         These are my opinions. There are many
<[email-masked]>   like them but these ones are mine.

---

From: Simon Tatham <[email-masked]>
Date: Thu, 28 Mar 2002 15:47:03 +0000

Richard Whalen  <[email-masked]> 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
<[email-masked]>    terminally confused is only apparent to the latter."