> Fixed (hacked around) in GIT hash e72f492.  Basically
> select() no longer works on newer systems (could be due to a malfunction of
> some kind, but it doesn't really matter), so instead of busywaiting on
> select(), newer systems will busywait on read().

I tested both sftp and fish using OpenSSH 5.5p1 at the client end and 5.7p1 at the other end.

I can SSH both ways using the terminal. I had no problems connecting to the 5.7p1 box with both sftp and fish.

I tested both sftp and fish using OpenSSH 5.5p1 at the client end and 5.9p1 at the other end.

I can SSH both ways using the terminal. I had no problems connecting to the 5.9p1 box with both sftp and fish.

I realize the suspicion is using OpenSSH > 5.5p1 at the client side and not the server side.

I tested both sftp and fish using OpenSSH 5.7p1 at the client end and 5.7p1 at the other end.

I can SSH both ways using the terminal. I had no problems connecting to the 5.9p1 box with fish but could not connect with sftp. I received an immediate error dialog:

Unexpected sftp error:2
error encountered while talking to ssh

I conducted these tests without the latest patch.

I rebuilt tdebase with the latest sftp patch.

I now no longer have a problem using sftp OpenSSH >5.5p1

The previous problem I described with fish failing occurs only when I run konqueror as root through tdesu. When I log into a Trinity session directly as root and then run fish I cannot repeat the failure. I can repeat the failure regularly when using fish through tdesu. Whenever I delete root's ksycoca cache then fish always succeeds when used through tdesu.

I can't replicate this fish failure with my KDE3 system. Running konqueror through kdesu works as expected.

These tests all were with the same OpenSSH 5.5p1 at both ends.

This failure describes a corner case but a nuisance bug nonetheless.

Good job with the patch. :)

Darrell