23 Apr
2012
23 Apr
'12
7:42 p.m.
Le 23/04/2012 09:44, Timothy Pearson a écrit :
I have narrowed this down to a problem in how ssh and select() are
interacting. To be specific, running select() on the open ssh output file
descriptor always returns data available, but when an attempt is made to
actually read said data with read() there is no data (an error occurs). I
do not know if this is an ssh problem or a problem with some other aspect
of the system regarding pipes.
Tim 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().
Tim
Thanks, it looks to work well on Fedora 16 (patch applied to TDE 3.5.13).
> On
04/22/2012 10:36 PM, Timothy Pearson wrote:
>> I just tested on my Debian Squeeze system with OpenSSH_5.5p1 and
>> OpenSSL
>> 0.9.8o, and sftp from GIT worked perfectly. I am going to try a
>> newer
>> system to see if I can get it to fail.
>>
>> Tim
>>
> Note, sftp from konsole will work PERFECTLY. It is sftp:// from the
> konqueror
> address field, or kwrite/kate that fails. Here is the debug output for
> a
> box
> that does not use key-pairs for authentication:
I know. :-) I am tracing the issue now, but it appears that ssh> 5.5
somehow masks its stderr output so that TDE literally does not know
what
ssh is doing.
Tim
To be more precise, it looks like select() is not blocking on the ssh
output file descriptors. This could also be a kernel or core system
issue, so stay tuned! :-)
Tim