










[dropbox_base]
type = dropbox
token = <token>
[dropbox_store]
type = alias
remote = dropbox_base:Store
[dropbox_crypt]
type = crypt
directory_name_encryption = true
filename_encoding = base64
filename_encryption = standard
password = <password>
remote = dropbox_store:
suffix = none
cipher_version = 2
I am able to upload a file to dropbox_base (including the Store folder directly), but it doesn't work in both dropbox_store and dropbox_crypt. I am getting this error (per screenshot):
Exception: upload failed: batcher is shutting down
I was able to manually upload the same file using rclone copy to all three targets. When I copied the file to dropbox_crypt with rclone, the file appeared on S3Drive in dropbox_crypt with an encrypted file name instead of the original name. I cleared everything out, used cipher_version = 1, repeated the process, and nothing changed.
The file is just test.txt with the contents test. I am using the Windows client v1.14.10 (build: 10141000). What might be wrong here? (edited)
cipher_version parameter is only supported by S3Drive, for Rclone it requires custom build: https://discord.com/channels/1069654792902815845/1069654792902815848/1410540245946208306
Having said that: cipher_version = 2 doesn't influence object filepath encryption, but only contents encryption, so it shouldn't really matter.
In our test case we've used below set:
[dropbox_base]
token = {"access_token":"<accessTokenHere>","token_type":"bearer","expiry":"0001-01-01T00:00:00Z"}
type = dropbox
[dropbox_crypt]
directory_name_encryption = true
filename_encoding = base64
filename_encryption = standard
password = apCcmC0mg3RyMGsRtnunNz0xwxWEGA
remote = dropbox_store:
suffix = none
type = crypt
[dropbox_store]
remote = dropbox_base:Store
type = alias
We could upload to both dropbox_crypt and dropbox_store on Windows using S3Drive without batcher issue and we could easily list these remotes, on e.g. Linux using Rclone CLI.
Not entirely sure why are you experiencing this issue.
Shortly we plan to release most recent 1.15.0 version, perhaps it might be worth to update once it's ready and we can then start further troubleshooting.


cipher_version parameter is only supported by S3Drive, for Rclone it requires custom build: https://discord.com/channels/1069654792902815845/1069654792902815848/1410540245946208306
Having said that: cipher_version = 2 doesn't influence object filepath encryption, but only contents encryption, so it shouldn't really matter.
In our test case we've used below set:
[dropbox_base]
token = {"access_token":"<accessTokenHere>","token_type":"bearer","expiry":"0001-01-01T00:00:00Z"}
type = dropbox
[dropbox_crypt]
directory_name_encryption = true
filename_encoding = base64
filename_encryption = standard
password = apCcmC0mg3RyMGsRtnunNz0xwxWEGA
remote = dropbox_store:
suffix = none
type = crypt
[dropbox_store]
remote = dropbox_base:Store
type = alias
We could upload to both dropbox_crypt and dropbox_store on Windows using S3Drive without batcher issue and we could easily list these remotes, on e.g. Linux using Rclone CLI.
Not entirely sure why are you experiencing this issue.
Shortly we plan to release most recent 1.15.0 version, perhaps it might be worth to update once it's ready and we can then start further troubleshooting. 
.blank file is ordinarily created with a new folder, and so just trying to guess that .blank encrypts to a specific string (and also other common names like Thumbs.db or System Volume Information, etc.). The encrypted file name should provide no information to what the actual one is. Things to consider are to (i) use a nonce and include it in the name, so that each file and folder name, even if they are the same in plaintext, would be different in ciphertext; and (ii) file names beyond a certain length are stored as part of the file's contents and excessively long folder names could include a metadata file inside; or (iii) all actual file/folder names within a folder are stored in a "header" file in the folder and encrypted there, and the "encrypted" names are just random identifiers referenced in the "header" file.



.blank file is ordinarily created with a new folder, and so just trying to guess that .blank encrypts to a specific string (and also other common names like Thumbs.db or System Volume Information, etc.). The encrypted file name should provide no information to what the actual one is. Things to consider are to (i) use a nonce and include it in the name, so that each file and folder name, even if they are the same in plaintext, would be different in ciphertext; and (ii) file names beyond a certain length are stored as part of the file's contents and excessively long folder names could include a metadata file inside; or (iii) all actual file/folder names within a folder are stored in a "header" file in the folder and encrypted there, and the "encrypted" names are just random identifiers referenced in the "header" file. beta integration.
a encrypts to g1jy and b encrypts to ne2k then:
a/b would be g1jy/ne2k,ab WOULDN'T be g1jyne2k, it would be entirely new string e.g. rnxu4qwe
You're right that such design leaks some context and isn't ideal, but there isn't ideal algorithm. Each has some compromises to make. Rclone encryption is simple and robust. Its determinisic feature allows easy rename (e.g. if you rename a then you don't need necessarily need to rename all files/folder inside a).
I sort of like your proposition:

