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

What is the problem you are having with rclone?

I'm migrating data from Google Drive to Dropbox, but get the error below on a few files with very long filenames.

 ERROR : pa9nk8oc9h5saam6vtenbghi64/qheh82msrotovfbo16g79s1r2m78akl1m06s11n8ct8kau0magl4m4vp0e0mfo0vdeh8aqc95ljik/cesdjupsedtmc2gctu9san00j4/5glhfef057D82adf2uobv6bjiosqfkakneiauorjoafai8dd0k2ut64qeg8pr16hui26tiubb59cvem1cdvf1l010i8j8djgifh9t3mmgspo6tcifom8k4gbgdd60mbsa6gcvkim3r967n9iu7s6f2pj0a4k5hs8ig60jh9ktssb0h7d0pb15u08rbd4g0nes2855t8g8a9015k1ulnct0ngfoipvoq701enc4239ke0jiubgg9e1puhfv1acnbl: Failed to copy: file name too long

The files are encrypted, and the crypt remote is set up like below. I'm copying encrypted files (via the main remote and not via crypt, but that should not matter).

type = crypt
remote = name:
filename_encryption = standard
directory_name_encryption = true
password = <redacted>
password2 = <redacted>

I've read a bit about base32768 and base64 filename encryption. I understand that base64 should be the best choice for dropbox?

Is there an easy way to convert an existing crypt from default/legacy encoding to the more effective base64 or base32768? Afaik it should mainly be renaming files, and ideally not require any redownload.

rclone version:

rclone v1.62.2
- os/version: debian 11.7 (64 bit)
- os/kernel: 5.10.0-19-amd64 (x86_64)
- os/type: linux
- os/arch: amd64
- go/version: go1.20.2
- go/linking: static
- go/tags: none

base64 is for case sensitive remotes - and Dropbox is case-insensitive. So it is not good choice.

The same with base32768:

I was actually thinking about creating new case-insensitive base32768 but it has not happened yet:)

So I would stay with base32. And yes you have to make sure your path is not too long. It is only 100% safe option for Dropbox.

1 Like

I swear I read someone recommended that for Dropbox, but all I find is OneDrive โ€“ so probably misread it.

Ok, thanks. I'll just have to rename things. It's thankfully not too many files.

well... you can use both base64 and base32768 on Dropbox - and people do.

It works but is not 100% safe - what is possible is that two encrypted filenames will collide e.g. for base64:


you could store two such files on Google Drive (case sensitive remote) but it is not possible in Dropbox.

Now what are chances that such situation happens? Very small for two files in the same folder. And even smaller for base32768.

But only base32 is 100% safe on remote like Dropbox.


There is a theoretical problem with base32768 and case insensitive remotes

However the probability of there being a problem is very close to zero. So close to zero that I have no problems recommending base32768 for use with Dropbox.

From the linked thread

I also tried harder to calculate the probability of this happening, and I think you'd have to put around 10ยฒยน files in a single directory before you got a collision, so I don't think it is very likely to happen ever.

Dropbox uses the right kind of encoding internally so that base32768 works really well.

So I would use base32768 on Dropbox!

1 Like

Yes chances are small:)

reminds me also that I have to finish my base32768 case-insensitive project. So paranoid people like myself can feel safe using it:) I have thoroughly tested alphabet ready - but still learning go in spare time. Case-insensitive is using different ranges than original base32768 and all encoding/decoding logic has to be re-written.

1 Like

Ok, great. Appreciate the insights.

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

Would base32768 be more or less safe on all of those? And how would you go about converting from the default encoding to base32768? (preferably with just renaming on the remotes).

only base32 is truly cross remotes encoding...

base32768 (forgetting theoretical problems) requires:

  1. remote to support full Unicode - should be ok in 2023
  2. remote counting UTF-16 or Unicode codepoint instead of UTF-8 byte length

The second point is that e.g. filename:


contains 9 Unicode code points... but it takes 18 bytes to encode them. If your remote counts bytes then all savings will be gone,

1 Like

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

$ rclone test info --check-length dropbox:check-length
// 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.

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.


Thanks! I'll try to get around to test this soon.

Is there a way to "reopen" old topics btw? Three days feel like a very short time, and you end up with many "duplicate" threads about the same subjects?

rclone move --server-side-across-configs seems to work great. The speed varies a bit on the different cloud providers, but nothing compared to having to download and upload. :+1:

1 Like

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