You are not logged in. You can browse in the PowerBASIC Community, but you must click Login (top right) before you can post. If this is your first visit, check out the FAQ or Sign Up.
Is there an FTP command like MPUT to copy files from one remote directory to another remote directory?
I'm thinking of writing a cgi program to do this on a windows server.
Is there an FTP command like MPUT to copy files from one remote directory to another remote directory?
I'm thinking of writing a cgi program to do this on a windows server.
Not in the basic RFC command set. SOME FTP servers will allow this, but most will not. I sure wouldn't do this if you are not in direct control over both FTP servers. If you are, then check the docs for that server as it will tell you what (if any) commands it accepts for server-to-server transfers.
What you're asking about is known as FXP, and very few servers will permit it. It works by having the client establish two connections, one to the source FTP server and the other to the desination server. On the destination server, the client requests a passive mode transfer, gets the IP address and port number, and issues the STOR command. The destination server is now waiting for the file data to store on the system. On the source server, the client then requests an active mode transfer and specifies the same IP address and port number that was provided by the destination server. The client issues the RETR command, the source server connects back to the destination server, and begins sending the file data.
This all works when the FTP server allows the PORT command to specify an IP address that is different than that of the client that's connected to it. However, this opens them to an attack known as "FTP bounce" where the FTP server can be exploited as a "middle man" used to scan ports or launch denial-of-service attacks against other servers. In other words, if you permit FXP outside of your own intranet, you're creating a significant security hole that can be exploited to attack others.
i just got through doing some testing with some programs i have written for tcp file transfers connections. i had placed in the source section of code that will only transfer a file only one way. the client can download and the server uploads. on both computers just place the server and the client.
the server will only allow for one password but you can run multiple instances of the server with different port number and place a different password in each server.
the software also lets you set the blocksize to send for tcp transfers, and i have had a problem with large blocksizes going over the internet.
the code to send to a server was remarked out and untested.
i have had problems on transfer speeds over the internet but the intranet is fast.
i may have just resolved my problems with the transfer speeds.
i am running windows 2000 pro and i have made changes to the tcp parameters in the os.
i changed the mtu to 1492 and tcp receive windows to 63888, we have dsl connections with pppoe
the testing was light, but without a problem so far, i was using a block size of 32000 bytes to transfer and there was no glitch, which before i had a problem sending anything above 5000 bytes.
It reduced the time in half.
paul
the programs where written for transferring more than one file at a time but you can run the server on a computer with more than one instance then (divide and conquer) have the client do two or more downloads at the same time running multiple instances of the client.
i did not want the client to send a file, because i did not what the client to write over a good file on the server and i have remote control software where i can go to the server and initiate a download using the same software.
.. so you could download (using post #1, the original, from which I shamelessly copied) from the source directory to your local PC, then upload (using post #2) to the destination directory.
We process personal data about users of our site, through the use of cookies and other technologies, to deliver our services, and to analyze site activity. For additional details, refer to our Privacy Policy.
By clicking "I AGREE" below, you agree to our Privacy Policy and our personal data processing and cookie practices as described therein. You also acknowledge that this forum may be hosted outside your country and you consent to the collection, storage, and processing of your data in the country where this forum is hosted.
Comment