Subject: filexfer: short reads

From: Jacob Nevins <[email-masked]>
Date: Fri, 1 Apr 2005 21:08:51 +0100

(This issue is present in filexfer-07, but not new in this version.)

Of SSH_FXP_READ, filexfer-07 states (sec 7.2.1):

| For normal disk files, it is normally guaranteed that this will
| read the specified number of bytes, or up to end of file.
| 
| If the server specified 'max-read-size' then failure to return
| 'length' bytes indicates that EOF or an error occured.

The "guarantee" in the first paragraph doesn't seem to be worth
anything, given the "for normal disk files" (undefined) and even more
vague "normally" hedging.

This is an issue particularly when a client attempts to optimise
transfers by having multiple requests "in flight" simultaneously, as
discussed in sec 10. For instance, if a client issues a series of
reads (say) 4k apart, and the server returns short reads (say 512
bytes), the client then has to have a strategy to fill in the resulting
gaps, and probably some heuristic to guess the read size for the rest of
the file (in the absence of 'max-read-size'). If this guarantee were
usable, this fragmentation/reassembly machinery would not be necessary.

(We've had a report of this in practice -- an OpenVMS server returning
short reads for a ZIP file, apparently due to an implementation detail.
My guess would be that there wouldn't be a way for an SFTP client to
tell that this is anything other then a "normal disk file".)

The "guarantee" should either be made useful, or removed. I suspect
that the right answer is to remove it in the absence of 'max-read-size'
information (especially as some reassembly capability is already
required of optimising clients in order to deal with responses arriving
out of order). The language that was added in sec 10 in -06 seems to
support this interpretation:

| Implemenations MUST also be aware that read requests may not return
| all the requested data, even if the data is available.

[typo "Implemenations" for "Implementations"]

---

From: Joseph Galbraith <[email-masked]>
Date: Fri, 01 Apr 2005 13:16:56 -0700

> vague "normally" hedging.

Thanks... I'll remove it.

> usable, this fragmentation/reassembly machinery would not be necessary.

This is exactly the reason I added the max-read-size for.

> tell that this is anything other then a "normal disk file".)

We also had this from a couple of embedded devices, that never
did anything more than 4K.

> support this interpretation:

Yep.

> [typo "Implemenations" for "Implementations"]

Fixed.

Thanks,

Joseph