Base32768 filename encoding with crypt + dropbox remote

[ncw (Nick Craig-Wood)]

@Lex

Are there known incompatibilities with a crypt remote using filename_encoding = base32768 and an underlying Dropbox remote?

I don't know of any.

@Lex

If the source filenames contain no emoji or 4-byte Unicode characters, might base32768 nonetheless create a 4-byte character when encoding?

The source file name can contain emoji but the base32768 encoding will never contain emoji and all code points in it are UTF-16.

You can check out the design of the encoding here: GitHub - qntm/base32768: Binary-to-text encoding highly optimised for UTF-16

@Lex

On the rclone.org/overview page you do mention Some cloud storage systems might have restrictions on the characters that are usable in file or directory names. When rclone detects such a name during a file upload, it will transparently replace the restricted characters with similar looking Unicode characters.. But I'm not sure if that applies also to a remote wrapped in a crypt remote.

It does apply, yes, but the characters we are talking about are ASCII characters like ?*: which the crypt name encodings will never generate.

@Lex

We've run a test uploading 10,000 or so files with base32768 encoding and so far not run into any issues. But there are in total several million files, thus would prefer to not hit it at the 3,888,888th file.

There are 32768 possible UTF-16 characters in the base32768 encoding. If you've uploaded 10,000 files it is very likely you've already uploaded all possible characters!

I made a selection of files with all characters from the encoding here: https://pub.rclone.org/base32768.zip

These files upload fine to dropbox so I think you will have no problem with base32768 encoding.

In fact I feel so confident of that I changed the crypt docs to recommend base32768 for onedrive and dropbox!