Possible to convert an existing crypt from default/legacy encoding to the more effective `base64` or `base32768`?

[ncw (Nick Craig-Wood)]

@nle

I have the same data in multiple cloud providers – with different settings (currently google, jotta and dropbox).

The way to test to see whether base32768 is a win is to use this

$ rclone test info --check-length dropbox:check-length
[snip]
// dropbox
maxFileLength = 255 // for 1 byte unicode characters
maxFileLength = 255 // for 2 byte unicode characters
maxFileLength = 255 // for 3 byte unicode characters
maxFileLength = -1 // for 4 byte unicode characters

// TestJottacloud
maxFileLength = 255 // for 1 byte unicode characters
maxFileLength = 255 // for 2 byte unicode characters
maxFileLength = 255 // for 3 byte unicode characters
maxFileLength = 127 // for 4 byte unicode characters

What you want to see is the length for 2 byte unicode characters to be the same as the length for 1 byte characters. The base32768 encoding uses 2 byte unicode characters.

So you are good to go on Jottacloud and Dropbox.

Max file length for Drive are enormous so you don't have to worry about that.

@nle

And how would you go about converting from the default encoding to base32768? (preferably with just renaming on the remotes).

What you do is set up a new crypt remote by copying the old one in the config file, renaming it and adding filename_encoding = base32768. Choosing a different destination directory is a good idea here too so the old and the new don't overlap.

You can then do a server side move something like

rclone move --server-side-across-configs -vv old: new:

This should do server side renames for you.

Test first with --dry-run and a small test.