If the server returned less than we asked for we're at EOF

[Amin Azez]

* David Collier-Brown wrote, On 28/11/07 16:20:
> No, less than read is sufficient if and only if you're looking at an
> unchanging file. 
I guess thats hard to tell without trying another read, maybe thats why
all the cifs clients I tried so far keep reading.
> (zero bytes read || feof) is sufficient IFF its an unchanging file
thats not what you just said. I'm not trying to be pedantic, I really
want to understand.

I think zero bytes read || feof is sufficient.

I'm asking if bytes-read < bytes-asked, because my samba experience
(ancient and modern) suggests not if bytes-read is also > 0
> EOF on a constantly growing file is just hard (;-))
indeed.

For my case (as a proxy) I'm trying to find out if returning a short
(non-zero) read because it's all I have right-now is dangerous because
the client would not be incorrect to act as if it were eof.

Sam
>
> --dave
>
> Amin Azez wrote:
>> * David Collier-Brown wrote, On 28/11/07 13:47:
>>
>>> Unix systems return less than asked on EOF, and after reaching
>>> EOF on an unchanging file will return 0 bytes and feof(fp) will
>>> returns non-zero.
>>
>> Aye, less-than-asked is returned on eof, but, can eof *reliably* be
>> inferred from less-than-asked? And in a cifs context?
>>
>> Sam
>>
>>> --dave
>>>
>>> Amin Azez wrote:
>>>
>>>> libcli/clireadwrite.c/smbcli_read
>>>>
>>>> says: If the server returned less than we asked for we're at EOF
>>>>
>>>> I'm aware that if it returns 0 bytes we're at EOF, is it strictly true
>>>> that less-than-asked-for also means EOF?
>>>>
>>>> My caching code returns smaller-than-asked-for reads if the full
>>>> amount
>>>> isn't in the cache, and so far no clients have interpreted this as
>>>> EOF,
>>>> but kept from where the previous read left off.
>>>>
>>>> Am I supposed to make use of the "remaining" field here?
>>>>
>>>> Sam
>>>>
>>>
>>
>>
>