On 04/25/2012 12:14 AM, Timothy Pearson wrote:
Just tdebase.
Tim
looks like it is finally fixed. Only error I saw was when "Adding" the sftp://server/ directory to the 'places' part of the file-save dialog. When I rt-clicked and chose 'Add Entry' -> the url was blank, even though I had already navigated to sftp://server/. It has always provided a directory name and the kio (eg: fish://, sftp:// and the current remote directory as the default directory to add. This is probably not sftp related, although the one I have with fish did what it was supposed to when it was added a while back??
Regardless, them are small potatoes compared to getting sftp:// back up and running! 2 years it was down. The white wizard pulled it off. Good job Tim.
Glad to be of assistance! :-)
Now even though I have the patch and I've looked at it, I still don't follow what changes you made - so could you help a brother out -- What was it??
You would need to know some of how kio_sftp operates to know what I did, so I will try to sum it up below:
kio_sftp can be invoked in two ways, as you are aware: one with a port number, and one without. Internally, kio_sftp runs an ssh process in verbose sftp mode in order to view/modify files on the remote system. To to this, kio_sftp passes required parameters and optional parameters, which kio_sftp generates internally based on information given, to the ssh process during process invocation.
Optional parameters include the port number--if the port number is not manually specified when kio_sftp is invoked, the port number parameter should not be passed to the ssh process, allowing ssh to connect on whatever default or preconfigured port it desires.
The recent problem arose due to the fact that the port number was ALWAYS being specified via the removed code. The new code sets mPort to -1 if a port number was not manually passed to kio_sftp, thus indicating that the optional port parameter should NOT be passed to the ssh process on invocation.
Does this make sense?
Tim