I would like to know if it is possible to start only 1 RCLONE instance and then run several different commands (like: lsjson, copy, etc) over it.
The documentation on the "--rc" flag ( Remote Control / API (rclone.org)) states that RCLONE will start an HTTP server.
But this does only work for a specific command. I find the docu about "--rc" "rclone rc", and "rclone rcd" really hard to understand. I do not get the actual purpose of each and what distinguishes one from the other and when to use one and when to use the other....
I would like to run several commands on the same remote, like:
first run a "lsjson" to get the content.
run a "copy" to copy specific files.
Do I have to start RCLONE each time I want to execute a specific command?
To read a specific file content I already use "rclone serve http ...".
What is your rclone version (output from rclone version)
rclone v1.57.0
os/version: Microsoft Windows 10 Enterprise 2009 (64 bit)
os/kernel: 10.0.19044.1415 (x86_64)
os/type: windows
os/arch: amd64
go/version: go1.17.2
go/linking: dynamic
go/tags: cmount
Which cloud storage system are you using? (eg Google Drive)
I would like to use any or all RCLONE supports.
The command you were trying to run (eg rclone copy /tmp remote:tmp)
Think of it like a webserver as you can run one webserver and do as many things as you like against that web server.
You start by spawning a rclone "webserver" in this example. You can do that by adding -rcd to your existing mount command.
I add:
--rc --rc-addr 127.0.0.1:5575
To my mount and that makes it remote controlable on the IP/Port listed above. You can run rclone rcd itself to spawn just a blank instance of rclone and do what you want there. You can run a rclone serve http with rc and do that. Options are quite large.
For controlling it, once you have remote control running, you can hit that "webserver" as many times / as many ways as you want but using the rclone rc command to hit against it.
So on my mounts when they load, I refresh their directory/file structure by using:
I think the problem I have, and what the docu on the "--rc" flag misses, is, that the webserver only works on a specific RCLONE command, like "mount" in your example here.
I would like to use RCLONE on many different machines (Windows, Linux, etc.) and, at least on Windows, you first need to install some additional software before you can use the mount command.
I'm looking for a way to start only 1 RCLONE process and then use it's API to run any of the available commands in RCLONE.
But from what I understand now, this is not possible.
On Machine A: run rclone rcd /rclone serve rcd / rclone mount /rcd / rclone anything with rc enabled
On Machine B: run rclone rc commands against Machine A
On Machine C: run rclone rc commands against Machine A
etc.
Ok, then I will explain my use-case in a bit more detail:
I would like to integrate RCLONE in my product to give my customers access to files stored on any of the cloud providers RCLONE supports.
A customer would then specify the connection details (remote, bucket, credentials, etc.) to connect to his/her preferred cloud provider.
I would then run a "rclone.exe lsjson remote:bucket ..." command to get all files.
After that I want to copy one or more files (from the same remote), so I run a second RCLONE command:
"rclone.exe copy remote:bucket/filename destinationfolder --inlcude "some filter" ...".
Would it be possible to run both commands on only one RCLONE process/instance?
so the "rcd" command starts the remote control server and not the "--rc" flag (as stated in the docu).
Ok, I can run this and it's waiting for input, cool.
But now, I have to start a second RCLONE process to query that remote control?
That would not give me any advantage in running one RCLONE process for "lsjson" and another one for the "copy" command.
You see, the whole point of my question was/is to have only one RCLONE process running on the customers computer and to use this, for example, over HTTP, like the "serve http" comand enables me to do.
Because of it's size (around 42MB) the RCLONE.exe file always takes a couple of seconds to start and if you need that multiple times, it adds up.
I'm currently developing the stuff on my Windows PC.
When I type "rclone.exe ..." and hit the ENTER button, it takes roughly 2 to 3 seconds before I see any output.
Ok, if I got this right now, I start RCLONE with the "rcd" command, like:
rclone.exe rcd --rc-no-auth --config="myConfig.conf" --rc-addr :5025
2021/12/17 15:42:33 NOTICE: Serving remote control on http://[::]:5025/
to have a HTTP server running that I can then query via any HTTP client to run a "operations/list", which seems to be the equivalent to the "lsjson" command?
I think, it also heavily depends on the security stuff your IT has put on your machine, e.g. virus scanner(s) and other security software which can influence how fast an application starts.
And in larger enterprises, those stuff is a thing one cannot ignore.
If it takes 5 seconds for a 42MB binary to return, something else is going on.
I'm running on a super tiny cloud VM that has windows to test on.
My background is in the IT landscape(Infra/Desktops/etc) and not a developer so if there are items on a machine that makes a 42MB binary take 5 seconds to open, something is not right.
I'd imagine you probably have an old machine with old spinning disk as that's just bonkers. If you run it twice, does it take 5 seconds?
When I run that measurement command multiple times in PowerShell, it goes down to roughly 200 ms.
But if I run my full RCLONE command from CMD (or from inside my application via Process.Start()) it always takes 2 to 3 seconds.
I'm not sure what that means. I was just running the binary as if you are executing something else after it, the remote/command/etc all can feed into the time that the command takes to run so a transfer might take 1 minute to complete but that's not really an accurate test of running a binary.
That would tell me something else is going on as if you have a SSD a read from a 42MB binary takes 5 seconds, there is something else afoot and that's beyond rclone support. Good luck!