pe.ch wrote:...plugin... ... add function ... identical like in classic FTP in TC
For sure, SFPT (/SCP) should become integrated part of Tc, like "classic FTP" in Tc and with the same features (and with external Libs, like FTPS in Tc, to prevent legal issues).
Unfortunately background operation isn't currently possible, because the plugin interface doesn't support it. Integration in the normal FTP client is also not possible (at least not easily) because FTP and SFTP are completely different things, they share only the name. SFTP and FTPS (over SSL) are very similar, though, so it was easy to integrate FTPS in the normal FTP client.
ghisler(Author) wrote:Integration in the normal FTP client is also not possible
Do we really need sftp integrated directly into TC? Wouldn't it be enough if it just behaved more like current integrated ftp? I mean centralized bookmarks, use of "<number> drive", etc. I think it wouldn't even be too complicated (at least some parts).
I played with it a little and the basic idea is this: extend FS plugin API with bookmark handling functions. When user opens "connect to ftp server" dialog, ask plugins for their bookmarks and display them together with internal ftp ones. Only two things are needed for it to work: a name to display and the path of the connection in plugin FS to open. Another function(s) would be needed to tell the plugin to add/edit/delete a connection. And that's all. Simple and backward compatible.
The whole thing would of course be optional. The plugins where bookmarks don't have much sense (undelete, ext2fs, ..) would just not export these functions.
This is what I played with (it very roughly shows the idea):
Copy path to clipboard works nicely with FTP but in SFTP the actual path is not copied. An option to copy the real path also in SFTP would be most welcome...
EDIT: After some more thinking, I have to admit that my request in that form may have been a stupid one. It seems that sftp links are quite complicated. Therefore, I think that a way to get a decent copy path option is to specify in each connection's settings a user-defined replacement pattern (as a special option only for "Copy Path") to get the actual path of the specified connection, e.g.
The path in TC is:
\\\Secure FTP\Server\Dir1\Dir2\Dir3\Dir4\file.txt
and to get the real path, the user sets the replacement pattern as e.g.:
2surrounder
Sorry, SFTP has only the name in common with FTP, but it works in a completely different way. Think of it like secure telnet (SSH) where a special channel is opened for file transfers (SFTP or SCP). Therefore normal FTP proxies cannot be used with it. The only other proxy types which could work would be Socks4/5.
2andres992
Sorry, this isn't possible with the current plugin interface.
1) Fixes HTTP CONNECT type proxy to work with IPv6 (fixed parsing of proxy hostname and CONNECT request) and Apache's mod_proxy (added "Host" header to request, because Apache wants it).
Works fine.
2) Adds support for SOCKS 4A proxy.
Works fine.
3) Adds support for SOCKS 5 proxy.
Not completely working. Connection to proxy is ok, (optional) authentication works, connection to destination host is established, packets start flowing, but ssh initialization always fails with "unable to exchange encryption keys" and I'm out of ideas how I could influence that.
Thanks a lot for these additions! I will soon integrate them into the plugin and then test why Socks5 fails ( I have a test proxy locally which works OK with FTPS).
Btw, can you recommend a patch tool for Windows? Currently I'm applying these all by hand. I have tortoisesvn installed for test purposes and .patch is associated with it, but it doesn't want to apply the patch because the files aren't controlled by svn...
This may be totally offtopical again but I have used the V_KLay freeware (http://www.vi-soft.com.ua/) to patch mobile phone binaries on my system disk. Apart from the fact that the app is meant for mobile phone fullflashes, I think it is possible to use V_Klay to apply any kind of binary patches through Flasher -> Open File ...
V_Klay has specific patch format (ordinary text files, where part of the file is the old binary segment and the other part is the new segment that replaces the old one).
Of course, if a specific binary patcher for Windows binaries comes up, it would probably be a better solution but I think V_Klay could be better than patching manually. Sorry if my recommendation is inappropriate, I was just trying to help...
Another one I have used is CodeFusion patch generator (http://www.kobik.net/codefusion.asp), which can "simply byte-patch at a particular offset".
I have put the SOCKS code from user "Sob" into the plugin now. It didn't work because the last SOCKS5 reply wasn't interpreted correctly, so some remaining SOCKS response remained in the data stream and made the SFTP negotiation impossible. I have also added support for SOCKS4 when the user has entered a numeric IPv4 address, and numeric IPv4 and IPv6 handling in SOCKS5.
There are also some more improvements in the new beta:
the complete connect process is now asnchronous, so the user can abort it at any time
the plugin now supports text file conversion from/to the Unix format (line feed only). The plugin tries to detect Unix servers in two ways: First it gets the environment variable $OSTYPE, and looks for Unix, Linux and Aix. Then it sends "ls -l" and looks for the type of line breaks sent by the server. Maybe someone has a better idea? Anyway, you can also configure it by hand.
text conversion is a bit more clever than the normal ftp servers: Files containing 0 bytes are not converted, and text files with Windows line breaks (0d 0a) are not converted again (would be resulting in 0d 0d 0a).
You can download the latest version 0.92 of the plugin from the first post of this thread now.
Please remember that this is still a beta version!
ghisler(Author) wrote:Btw, can you recommend a patch tool for Windows?
I use the same as Hacker already suggested. Not exactly very user-friendly, some nice gui would help sometimes, but it works.
ghisler(Author) wrote:It didn't work because the last SOCKS5 reply wasn't interpreted correctly, ...
Stupid error. :) But looking at the new code, I'd say there's brand new error there too. :) In case 3, buf[4] is not available. You can either read 5 bytes as I did (instead 4) and then read one less than needed for address, or read the extra byte (with domain name length) in case 3.
