Re: filexfer: short reads

[Joseph Galbraith <galb-list%vandyke.com@localhost>]

Jacob Nevins wrote:
> (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.

Thanks... I'll remove it.

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

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

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

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

> 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:

Yep.

> | 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"]

Fixed.

Thanks,

Joseph