How to change config location when using librclone

What is the problem you are having with rclone?

I'm using librclone, but I'd like to have the program's configuration file at a custom location.

Run the command 'rclone version' and share the full output of the command.

$ rclone version 
rclone v1.53.3-DEV
- os/arch: linux/amd64
- go version: go1.18

My program is using the Rust bindings of librclone though, which appear to be on version 1.56.

Which cloud storage system are you using? (eg Google Drive)

N/A

The command you were trying to run (eg rclone copy /tmp remote:tmp)

I ran config/create from the RPC interface to login to my account, and found that the config got stored at ~/.config/rclone/rclone.config. I have the RCLONE_CONFIG environment variable set to ~/.config/{my-program-name}/rclone.config though, and it's thus appearing that setting RCLONE_CONFIG is having no effect.

The rclone config contents with secrets removed.

N/A

A log from the command with the -vv flag

N/A

I had a look through the code and I think setting RCLONE_CONFIG should work.

Is it definitely set in the process which has loaded librclone?

As far as I'm aware it is, manually checking the environment variable in my program is showing that it's indeed set as well.

I don't know much Go so I don't know how much testing I can do, but would you be able to see if you get any luck on your end?

I just followed the instructions for building the C library that are shown here, and attempting to run the following code appears to always load the config from ~/.config/rclone/rclonf.config, even if RCLONE_CONFIG is set:

#include "librclone.h"
#include <stdio.h>

int main(int argc, char *argv[]) {
        RcloneInitialize();
        printf(
                "%s",
                RcloneRPC("config/listremotes", "{}").Output
        );
}

Yes this does appear to be broken.

I made an RPC to set the config path - can you give this a go?

v1.61.0-beta.6585.55326adbb.fix-rc-config-setpath on branch fix-rc-config-setpath (uploaded in 15-30 mins)

config/setpath: Set the path of the config file {#config-setpath}

Parameters:

  • path - path to the config file to use

Authentication is required for this call.

Sorry for the late reply, I got busy with some stuff and didn't get a chance to really look into this until now.

Anyway your change makes everything work correctly - is there any reason the environment variable method wouldn't work instead here though? I'm just thinking about potentially wanting to use other CLI flags in the future, and being able to set those via environment variables would be quite convenient

librclone doesn't parse the CLI flags, and hence doesn't read environment variables.

However you can set nearly all of rclone's config via the API.

You can set this on a global basis, or on a local (per command) basis.

--config is missing from that list along with a small number of flags like --retries and --stats (you are expected to do your own high level retries via the API).

It should be a complete list!

You can see the options with rclone rc --loopback options/get

What flags do you want to set?

librclone doesn't parse the CLI flags, and hence doesn't read environment variables.

That's fair, I didn't think about it being implemented there. I thought it might've just been some global application code or something.

However you can set nearly all of rclone's config via the API.

I didn't think about that either, I completely forgot seeing that the other day, and that probably would solve pretty much anything I need. I can see how --config would be the exception in this case - there's no specific flags I was needing set, it was more of a mindset of thinking about potential future needs (though none have been present yet).

I think the way that branch handles things is fine then, I'm fine with getting that into the codebase as soon as you are

I've merged the config file api to master now which means it will be in the latest beta and released in v1.61.0

1 Like

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.