Paramiko throws EOFError rather than returning a 0 length file or ENOENT

[Robey Pointer]

On 12 Sep 2006, at 8:06, John Arbash Meinel wrote:

> Vincent Ladeuil wrote:
>>>>>>> "jam" == John Arbash Meinel <john at arbash-meinel.com> writes:
>
> ...
>
>>     jam> So this may be a reason to introduce a TransportFile,
>>     jam> which is file-like, only it handles translating a
>>     jam> transport specific exception into a generic exception.
>>
>> http faces the same kind of problem, the reads can (today for
>> pycurl, in the future for urllib) occur outside the scope of the
>> transport, so having a TransportFile, if not necessary now, can
>> solve future problems.
>>
>> +1 on the concept
>>
>>    Vincent
>
> I think it is just a question of what should a file raise if it gets
> truncated. A standard file just returns a short read, but no  
> exception.
> Would bzr handle that properly? Or do we really prefer getting a
> Disconnected error.
>
> I'm tempted to say Disconnected, because I don't know what a short- 
> read
> would really do. I *think* it would be safe, as long as the next  
> action
> was Disconnected. The readv stuff doesn't actually assert that the
> lengths it reads are correct. It should, though.

I agree; I don't think that kind of error should be hidden.  It could  
lead to silent corruption.


> On that note, should it keep trying to read more until it gets the  
> full
> length, and fail only if it gets a 0-length read, or should it just  
> fail
> on the first wrong-length read?

As Vincent points out, a short read isn't necessarily an error,  
especially over sockets.  Paramiko tries to hide this but it's  
probably still an issue for http, for example.

I believe an error like "server disconnected" should always be  
reported as some kind of exception (at the API level).

robey