Subject: Re: Questions on reading a writing of text files....

From: "Joseph Galbraith" <[email-masked]>
Date: Mon, 7 Oct 2002 07:18:58 -0600

> The draft draft contains the following:
>
> 6.4 Reading and Writing
>
>    Once a file has been opened, it can be read using the SSH_FXP_READ
>    message, which has the following format:
>
>    uint32     id
>    string     handle
>    uint64     offset
>    uint32     len
>
>    where `id' is the request identifier, `handle' is an open file handle
>    returned by SSH_FXP_OPEN, `offset' is the offset (in bytes) relative
>    to the beginning of the file from where to start reading, and `len'
>    is the maximum number of bytes to read.
>
>    In response to this request, the server will read as many bytes as it
>    can from the file (up to `len'), and return them in a SSH_FXP_DATA
>    message.  If an error occurs or EOF is encountered before reading any
>    data, the server will respond with SSH_FXP_STATUS.  For normal disk
>    files, it is guaranteed that this will read the specified number of
>    bytes, or up to end of file.  For e.g.  device files this may return
>    fewer bytes than requested.
>
>    Writing to a file is achieved using the SSH_FXP_WRITE message, which
>    has the following format:
>
>    uint32     id
>    string     handle
>    uint64     offset
>    string     data
>
>    where `id' is a request identifier, `handle' is a file handle
>    returned by SSH_FXP_OPEN, `offset' is the offset (in bytes) from the
>    beginning of the file where to start writing, and `data' is the data
>    to be written.
>
>    The write will extend the file if writing beyond the end of the file.
>    It is legal to write way beyond the end of the file; the semantics
>    are to write zeroes from the end of the file to the specified offset
>    and then the data.  On most operating systems, such writes do not
>    allocate disk space but instead leave "holes" in the file.
>
>    The server responds to a write request with a SSH_FXP_STATUS message.
>
>
> When operating in text mode, should a read just return one line (with the
> appropriate end of line sequence), or should it fill the buffer,
separating
> each line with the end of line sequence.  What if a line has more
characters
> than are available in the buffer, should the portion that fits be returned
> and the remainder saved for the next read?
>
> There are fewer questions about writes, but what should be done with a
write
> that does not end in the end of line sequence?  Should it wait for another
> write that contains the sequence and the two be appended?

Good questions.  I was assuming the operating characteristics of read and
write would not change, which means partial lines could be both read and
written.  This is definitely the simplest way to go in terms of the amount
of verbiage needed for the draft.  (For example, line is too big for buffer
question just goes away.)

Is it too onerous to implement, do you think?

- Joseph

---

From: Richard Whalen <[email-masked]>
Date: Mon, 7 Oct 2002 10:24:56 -0400

> > I think that a line stating "All end of line sequences are 
> explicit when
> > operating on a file in text mode." would eliminate any confusion.
> 
> I'm not sure where this text would go?  Is this more along the lines
> of 'partial eol sequences should be ignored'?  I currently have some
> text in there about that (added after posting draft-draft in response
> to someones feedback.
> 
> Thanks,
> 
> - Joseph
> 
> 

I think that it may be covered by your text that states that partial eol
sequences should be ignored.