[rfc] [patch] sftp unit tests without ssh

[John A Meinel]

Robey Pointer wrote:
> 

...

>>> Is it a time when we are trying to write to a closed socket? Like on the
>>> client side we got an exception an exited, rather than continuing?
>>>
>>> I'm just worried that if we catch all socket exceptions and throw them
>>> away, we might miss future bugs.
> 
> 
> Paramiko implements destructors for file objects, so they can behave as
> much like python file objects as possible,  The destructor does an
> equivalent of "close()" except, since it's being executed in what may be
> an inconvenient place, it doesn't wait for a server response.  It makes
> one quick attempt to send a clean "close the file" request to the
> server, ignores errors, and then returns.
> 
> At least a few of the unit tests rely on this behavior instead of
> explicit close() -- which is fine.  It just means the stub "server" may
> try to send a status response to the close() request and find out that
> the socket has already been closed.
> 
> I think it's safe to just catch and throw away *all* socket errors in
> the stub server, because it's running in a different thread.  If it's a
> bug in the server that causes an operation to fail, we'll notice in the
> unit test thread and fail an assert.
> 
> (The normal behavior for an sftp server that gets disconnected like that
> would be to log a debug message maybe, and then shut down the session. 
> That's effectively what we're doing.)
> 
> 
>> Does socket.error have any more specific information, so we can detect
>> "connection closed" or something like that? I would really prefer a
>> specific error trap, rather than an unspecified one.
> 
> It looks like socket.error on posix includes errno info -- unportable
> garbage.  I believe I've heard reports that on Windows it's a wrapper
> for a completely different winsock error object.
> 
> But, as I said above, since this is part of the stub sftp server, I
> think it's okay to just catch and ignore all socket errors.  If it was
> in the unit test or SFTPTransport it would be a different story.
> 
> robey
> 

Good enough for me. Added to jam-integration (1513), minus the traceback
for real exceptions.

John
=:->

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 249 bytes
Desc: OpenPGP digital signature
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20060126/bd4cc08d/attachment.pgp