Ok, then I did not misunderstand I think.
The configuration you have shown does not match what you are describing.
I suspect you are thinking about it in reverse.
In the end you will be mounting the crypt (with your current config).
your crypt points to the chunker
and your chunker points to the pcloud remote.
That will result in
OS --> crypt --> chunker --> pcloud
that will make encrypted chunks, but since hte encryption is on the "inside" and the chunking is on the "outside" then you will see the chunking format in the raw files.
This is not "wrong", but it does not obscure the data as well - since you can see what chunks are grouped together. Ie. it provides no real obscuration of the size if that is your goal.
If you reverse the chunker and the crypt so..
you mount the chunker, and point it to your crypt
and point the crypt to pcloud
then you will get
OS --> chunker --> crypt --pcloud
then the files will be split first, then encrypted - resulting in raw files that are very obscured and can not be recognized as groups (unique filesnames due to salt - and no extensions revealing that a chunker was used).
Here is what that sort of setup would look like:
type = pcloud
token = XXXXXX
type = crypt
remote = pcloud
filename_encryption = standard
directory_name_encryption = true
password = XXX
password2 = XXX
type = chunker
remote = pcloudCrypt
chunk_size = 100k
hash_type = md5
To use all three chained you would use pcloudCryptChunk to mount or interact with.
Note the physical order of the remote in the config foes not matter. I just rearranged them to make traffic easier to visualize. Traffic from OS to cloud moves from bottom to top. Then the traffic from could to OS move the other way, in reverse - top to bottom.
I hope I am not misteaching you. I have not extensively used the chunker myself yet, and I don't like it when darth disagrees with me, because I know he typically knows his stuff. Let me know if there are any special rules regarding chunker ordering that I am not aware of darth