Sven Giermann wrote:@JOUBE:
I did not try PSFTP, but as you quoted PSCP used sftp by default and returns the same throughput. So would like to have a '-scp' switch for our sftp-Plugin as well...
Sure, that pscp's "sftp protocol" "self checked" and "forced" is the same?
Maybe it's different.
Sure, that pscp uses in your case (with your server) in the "self check mode" the "sftp protocol"?
JOUBE wrote:Sure, that pscp uses in your case (with your server) in the "self check mode" the "sftp protocol"?
Yes, it does and the throughput is the same.
I did not know pscp's behaviour, but I saw that it's too slow, so I tried '-sftp' first with the same result and '-scp' with better results - always reproducable.
I cannot do any further checks at the moment (WinSCP) because the server is our gateway, which I sometimes use to download big files and get them later over the LAN. I deleted these files now and cannot mesaure the speed again.
I have now looked at the internals of the SCP and SFTP protocols, and I understand now why SCP must be faster: With SCP, the client requests or sends a file as a single stream, all in one part. With SFTP, the client request or sends small parts of the file, all separately, which are all confirmed one by one by the server.
Therefore I have now implemented SCP uploads and downloads in my plugin, and indeed they seem to be faster with a quick client and server! You can enable this option in the connection options (Alt+Enter on a connection).
You can download the new plugin version 0.9 from the first message of this thread. This version also includes the chmod fix when creating directories, and is already prepared for the master password manager of the upcoming Total Commander 7.5 (not available in TC 7.04a yet).
ghisler(Author) wrote:You can download the new plugin version 0.9 from the first message of this thread. This version also includes the chmod fix when creating directories, and is already prepared for the master password manager of the upcoming Total Commander 7.5 (not available in TC 7.04a yet).
Thank you for the update.
And thank you, that it is possible to set up a path on the server in the configuration for connections. But it's better, I think, to have this path in a separate field on the configuration page, like it is in the ftp modul of tc.
ghisler(Author) wrote:I have now implemented SCP uploads and downloads in my plugin
And now "it's a small step for man, but a great step for the"... plugin and the user to implement the whole scp communication protocol for servers without SFTP... (No, I know, it needs some more steps.)
JOUBE
Last edited by JOUBE on 2008-11-21, 12:05 UTC, edited 1 time in total.
p=strchr(tmp, ':');
t=strrchr(tmp, ':');
if (p && p==t) {
If there's any colon present, then there are two choices:
- first and last colon are same => there's only one colon => must be port separator
- first and last colon are different => most probably numeric IPv6 without square brackets
I also tested SCP with the OpenSSH server that I use. I did not change any other settings (that have previously worked perfectly with SFTP) but only checked the SCP box.
Smaller files (let's say 100-200 KB) are uploaded well but with larger files -- which do not contain any spaces in the name -- (I tried with 4MB etc.) the upload started but did not finish: I got an "Error Uploading File" message. Large files (up to 22 MB) downloaded OK.
The server configuration is probably OK since when I tested with WinSCP (profile set to use only SCP), the same files uploaded without problem.
I can also confirm that files with spaces in the name cannot be neither uploaded nor downloaded (the same error message).
• Just a modest thought : Couln't the spaces in these file names be converted into hexa value %20 ?
- Or into ANSI #160 which is seen generally as a "normal" character …
the SCP upload/download seems only to work when the directory/filename does not contain spaces...
I have checked that - the workaround seems to be to pass the file name in double quotes "".
larger files -- which do not contain any spaces in the name -- (I tried with 4MB etc.) the upload started but did not finish
After a long research I found that this is a bug in the libssh2 dll which was documented here: libssh2 SCP upload issues
The bug was report already in February, but not fixed so far. The only workaround seems to be to switch from non-blocking mode to blocking mode sockets. I'm doing this now just during the transfer, and it seems to work fine for me. Please download the new beta 0.91 from the first message.
The only workaround seems to be to switch from non-blocking mode to blocking mode sockets. I'm doing this now just during the transfer, and it seems to work fine for me. Please download the new beta 0.91 from the first message.
I tested 0.91 and uploads of larger files, which previously did not finish, were now completed correctly.
EDIT: I also noted that SFTP connections can be added to directory hotlist. However, doing it in the form:
cd \\\Secure FTP\Connection Name\
does not open the specific directory which I have set in the configuration for the respective connection (but instead opens just the site root). Not exactly a bug but I discovered that when I configure dir hotlist according the following pattern:
cd \\\Secure FTP\Connection Name\Path\on\the\Server\
everything works (i.e. the working SFTP path can be copied e.g. by opening Synchronise Dirs dialog and copying the full path of the remote directory from there). Is this intended behaviour, though?
Unfortunately, space is not the only naughty character. I was thinking about something like this:
Masking double Quotes is problably not needed because Windows doesn't support file names with double quotes anyway. Did you find out what characters don't work, e.g. what about the semicolon or other separators?
I tested 0.91 and uploads of larger files, which previously did not finish, were now completed correctly.
Great!
cd \\\Secure FTP\Connection Name\Path\on\the\Server\
everything works
The CD command will always go to the real directory in the plugin shown during a connection. The connection names themselves are just links which start the connection.
cd \\\Secure FTP\Connection Name\
has to go to the root because otherwise there would be no way to go there via the cd command...
KR
