thanks, @asdffdsa! I'll try it out.
does that mean that, as a rule of thumb, apart from the type, all the other parameters are named exactly as in the config file?
final question: is there a way to let rclone pick a password and a salt, printing both out for safekeeping?
perhaps rclone should check the flags better as i have shown rclone will create the crypt with filename_encryption true
and it will encrypt my passwords without the need for obscure
okay, I've tried again, running the latest beta (like earlier).
if I execute your example, rclone does obscure the passwords.
if I execute a real life scenario with a long password, rclone does not obscure it.
I guess somewhere there is some logic that says "if I get a value which is long enough, I'll assume it's already obscured", and that's why my passwords were clearly visible in the config file!
you can try again yourself with password my_very_long_and_stupid_password... it does not get obscured for me!
I've always been using the beta, v1.51.0-360-g518d3981-beta on Linux.
my point is that rclonedoes different things based on the length of the password value (and password2).
have you tried re-running your command but specifying my_very_long_and_stupid_password as password? does it still obscure it, in your case?
does this mean that I already had the --obscure and --no-obscure flags in my version, v1.51.0-360-g518d3981-beta?
still, isn't it a bug that rclone picks either flag based on the length of the password value?
or am I mistaken?
thanks, Nick! I did look at the docs before opening the issue, of course, but it was not entirely clear to me. is this command:
also, I'm guessing that I have to start with rclone config create thecrypt crypt and then I have to append the arguments, but it's not really clear to me.
after all, the "crypt" page talks mostly about the crypt remote, and I wouldn't know how to interpret the "standard options" that I see mentioned about the "crypt command" when I'm applying those to the "create" command.
I hope you at least understand some of my confusion.
I'm not sure exactly what that beta is, but if you check for the flag, that is your best bet.
It automatically tries to understand what you want. If you don't want that, you'd pick either option and go that route to force a direction based on your needs.
if I'm not interpreting the beta labels wrong, the github issue got fix and pushed to v1.51.0-330-g98c34e41-beta, and since I was using v1.51.0-360-g518d3981-beta the answer was yes, I had that flag.
I guess the most up-to-date answer, which works in the current beta and will work starting with v1.52, is something like:
I know, but I believe that THAT's the cause of the confusion.
explicit is better than implicit -- pick a behavior and people will adapt by using flags to accomplish their goals.
otherwise, there will be someone (like me! lol) trying a command with password shortpwd and seeing that it gets obscured, only to try the real-life case of a long password and getting burnt by this behavior.