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