On Mon, 2006-09-11 at 14:41 -0500, John Arbash Meinel wrote:
> Robey Pointer wrote:
> >
>
> ...
>
> >>> bzr is 0.9-0ubuntu2, the rest of the system is up-to-date edgy.
> >>
> >> Looks to me like paramiko is being unfriendly here. We should probably
> >> catch this and turn it into either ENOENT or a 0 length file, depending
> >> on what Robey says is happening.
> >>
> >> affects /products/bzr
> >
> > It looks like the underlying server connection vanished. I should
> > translate that into an SSHException for the next version, but I'm not
> > sure if that should be treated as ENOENT or an empty file. It probably
> > should just be treated as a "fail" error and let the user retry. (In
> > other words, same as now, but without the stack trace.) ;)
> >
> > robey
>
>
> Well if the connection goes away, then we would probably prefer to
> translate it into ConnectionError on our end.
> The problem is that this is happening at 'read()' time, not at 'get()'
> time. So it can't be wrapped by the transport. Either the transport
> needs to return a wrapped file object, that translates read()
> exceptions, or the bzr core needs to start understanding transport
> specific errors.
>
> So this may be a reason to introduce a TransportFile, which is
> file-like, only it handles translating a transport specific exception
> into a generic exception.
Well, all servers can fail badly during read(). Its just that we're
getting an error we dont understand during this particular one.
I think a global TransportFile is probably not needed, but we may need
one for sftp to solve this bug with current paramiko (which is all we
can be sure users will have).
On Mon, 2006-09-11 at 14:41 -0500, John Arbash Meinel wrote:
> Robey Pointer wrote:
> >
>
> ...
>
> >>> bzr is 0.9-0ubuntu2, the rest of the system is up-to-date edgy.
> >>
> >> Looks to me like paramiko is being unfriendly here. We should probably
> >> catch this and turn it into either ENOENT or a 0 length file, depending
> >> on what Robey says is happening.
> >>
> >> affects /products/bzr
> >
> > It looks like the underlying server connection vanished. I should
> > translate that into an SSHException for the next version, but I'm not
> > sure if that should be treated as ENOENT or an empty file. It probably
> > should just be treated as a "fail" error and let the user retry. (In
> > other words, same as now, but without the stack trace.) ;)
> >
> > robey
>
>
> Well if the connection goes away, then we would probably prefer to
> translate it into ConnectionError on our end.
> The problem is that this is happening at 'read()' time, not at 'get()'
> time. So it can't be wrapped by the transport. Either the transport
> needs to return a wrapped file object, that translates read()
> exceptions, or the bzr core needs to start understanding transport
> specific errors.
>
> So this may be a reason to introduce a TransportFile, which is
> file-like, only it handles translating a transport specific exception
> into a generic exception.
Well, all servers can fail badly during read(). Its just that we're
getting an error we dont understand during this particular one.
I think a global TransportFile is probably not needed, but we may need
one for sftp to solve this bug with current paramiko (which is all we
can be sure users will have).
-Rob www.robertcolli ns.net/ keys.txt>.
--
GPG key available at: <http://