Base32768 encoded filenames appear to contain characters that result in a 400 error

[Oval0149]

@ncw

@Oval0149

I am now testing whether I get an error on any of those when configured with filename_encoding = base32768 only and will report back.

I would have thought that you won't be able to access them.

I'm configuring a separate crypt remote as you described and so can access each variation separately. The source remote is stored on GDrive using filename_encryption = standard, and those files are all fine. The issues that I am seeing are arising when trying to convert to these particular crypt configs. The motivation for moving from filename_encryption = standard was to gain additional path length, as I'm finding that I'm unable to migrate existing files from GDrive to Dropbox due to Dropbox's relatively shorter maximum filename length. Hence, I've been trying to implement your suggestion in this post.

@ncw

If you use base64/base32768 then the original file names are completely obscured and dropbox won't care. If you use obfuscate then there can be parts of original file names which cause trouble - that might be what is happening here.

Great to know. When both config options are specified, does it seem that the obfuscate option is taking precedence? From what I can glean, the base32768 encoded output looks very different than the examples I saw with obfuscate, and the filenames being generated when I combined the two looked far more like the latter.

@ncw

Can you tell what the character was in the original file name?

Yes, the ERROR line in the original log emits the plain filename and I've been eyeballing to see which characters are causing it. From eyeballing, I've seen this occur:

• ’ becomes ⁳
• ‘ becomes ⁲
• … becomes ₟
• ’ becomes ₏
  (among others).