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).
[name]
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.
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.
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.
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).
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.
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.
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.
