Bug 66113 - FXP support in ftp://-protocol
Summary: FXP support in ftp://-protocol
Status: RESOLVED INTENTIONAL
Alias: None
Product: kio
Classification: Unmaintained
Component: ftp (show other bugs)
Version: unspecified
Platform: Debian testing Linux
: NOR wishlist
Target Milestone: ---
Assignee: David Faure
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2003-10-16 15:34 UTC by Mattias Hermansson
Modified: 2005-12-16 02:55 UTC (History)
0 users

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Mattias Hermansson 2003-10-16 15:34:04 UTC
Version:            (using KDE KDE 3.1.4)
Installed from:    Debian testing/unstable Packages

It would be really neat if when you drag and drop files from one ftp-site to another kio_ftp would first try to fxp the file(both methods) and only as a last resort bounce on local computer.
Comment 1 Thiago Macieira 2003-10-17 00:06:48 UTC
There is a limitation in KIO that has to be lifted. This has been reported before, but I can't find the report.
Comment 2 David Faure 2003-10-17 12:05:51 UTC
Subject: Re:  FXP support in ftp://-protocol

On Friday 17 October 2003 00:06, you wrote:
> There is a limitation in KIO that has to be lifted.
Wrong, KIO has support for copy().
It's only a missing feature in kio_ftp.

Comment 3 Thiago Macieira 2003-10-17 19:59:09 UTC
Sorry, I can't see it. KIO::FileCopyJob can't do direct remote-to-remote transfer without doing using the "data pump". It doesn't seem to be hard to do, except that one of the two kio_ftp slave would have to receive through metadata the address the other host is listening to.

As for the slave itself, it has to have a different handling for FXP than normal file get/put: it has to try PASV/EPSV first, then try PORT/EPRT at the other host and see if they work. Only then can it sent REST & STOR commands.
Comment 4 David Faure 2003-10-17 22:38:30 UTC
Subject: Re:  FXP support in ftp://-protocol

> Sorry, I can't see it. KIO::FileCopyJob can't do direct remote-to-remote transfer without doing using the "data pump".

FileCopyJob::startCopyJob()

Comment 5 Sebastian Wiedenroth 2005-12-15 22:30:02 UTC
Has this ever been implemented? At least it doesn't work over here.
I'd also like to make some suggestions. (I'm not sure if i should have made an extra report for every suggestion as they are very closely related to this one)

* If [1] is implemented it would be great if SSCN (set secured client negotiation) [2] would also be implemented. Changes would be minimal. KFTPGrabber has already support for it. I'd love that feature. :)

* If FXP is up and running, it would rock if support for direct-server-to-server transfers with other network protocols could be made available. So you can just drag and drop a file from one SSH server to a second one and all the data will be sent directly without the need of first downloading, going through kio and then uploading everything. (this is how it currently works i think)

* I have to admit that the next idea is really crazy and probably could end up in a lot of messy code if not done right. Perhaps this would even require some changes in the API. Some network protocols are extremely flexible (I'm thinking of fish here) that it could be possible to write a remote "translator" which enables one to copy directly within different protocols. For example i could "FXP" one file from a fish connection to a ftp server with just one drag! That feature, if implemented, would be the absolute killer.


[1] http://bugs.kde.org/show_bug.cgi?id=66117
[2] http://www.raidenftpd.com/kb/kb000000037.htm
Comment 6 Thiago Macieira 2005-12-16 02:55:49 UTC
No, FXP hasn't been implemented nor will ever be. The use-cases for it are just too narrow for kio_ftp.

FTP-specific applications, like KFTPGrabber, can implement it. We will provide the necessary support in kio_ftp, given the application's requirements (i.e., probably the ability to send arbitrary commands and to do a RETR without the corresponding PORT/PASV).

As for other server-to-server connections, I won't implement either. We just don't know if they are capable of speaking to each other. Unfortunately, the Internet isn't IPv6 and firewall-free. So the datapump through kio stays.