This requires the cURL extension to compile and use!
Currently i've only implemented uploading file(s) to a ftp server, but i might also add some other stuff over time.
This can't be considered stable (yet). Don't trust it. I might even change the natives... you have been warned.
It uses a configuration scheme similar to databases.cfg. It expects a file RemoteTargets.cfg in your config folder that looks like this:
Code:
"RemoteTargets"
{
"example"
{
"host" "example.com"
"port" "21"
"user" "ftpuser"
"password" "ftppass"
"path" "/"
"ssl" "try"
"CreateMissingDirs" "1"
}
}
You could then use this native + callback to upload a file to that target:
PHP Code:
functag EasyFTP_FileUploaded public(const String:sTarget[], const String:sLocalFile[], const String:sRemoteFile[], iErrorCode, any:data);
native EasyFTP_UploadFile(const String:sTarget[], const String:sLocalFile[], const String:sRemoteFile[], EasyFTP_FileUploaded:func, any:data = 0);
Example:
PHP Code:
EasyFTP_UploadFile("demos", "myDemoFile.dem", "/", EasyFTP_CallBack);
and
PHP Code:
public EasyFTP_CallBack(const String:sTarget[], const String:sLocalFile[], const String:sRemoteFile[], iErrorCode, any:data)
{
if(iErrorCode == 0) // These are the cURL error codes
{
PrintToServer("Success. File %s uploaded to %s.", sLocalFile, sTarget);
} else {
PrintToServer("Failed uploading %s to %s.", sLocalFile, sTarget);
}
}
This will upload the file
myDemoFile.dem to the
demos target and report the result using
PrintToServer.
Changelog:
Can be found on
github.
Some Notes:- A target does not need to have a path specification. This is meant for the consumer of your plugin to configure where he wants the files to be put. The remoteFile you are specifying in your code is appended to that path.
- You can omit leading slashes.
- If you specify a trailing slash for the remote file, it uses the same basename as the local file.
For example EasyFTP_UploadFile("demos", "/srcfolder/mydemo.dem", "/asdf/", CallbackFunc); uploads to /asdf/mydemo.dem.
- This plugin queues your upload commands, so only one file will be transferred at a time and the queues will be processed in the order they appear in the config file - which means files will not necessarily be uploaded in the order you've added them if you are uploading them to different queues.
This also means that an queue that always has a job in it blocks all following queues, which is a bug i have to fix. As long as you are operating on a single target or only on targets that don't tend to have an upload running all the time, you should be fine.
Known Bugs/Issues- I've only tested this with binary transfers, no idea what happens when transfering an ASCII file, but i guess you should be fine.
- The method this plugin reads binary data is awful, but i couldn't manage to not get 4 byte blocks by ReadFile(). Suggestions are very welcome.