23 Apr
2012
23 Apr
'12
4:38 p.m.
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