25 Apr
2012
25 Apr
'12
12:05 a.m.
On 04/25/2012 12:14 AM, Timothy Pearson wrote:
Glad to be of assistance! :-)
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. 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