There is no cap on the length. It will be cooked down to a 256 bit hashed key before being used to encrypt another key.
Thanks for that. The database is pretty empty, except for some logs on transfers:
These look disturbingly similar to the ones I found for another issue.
It looks like a bunch of uploads were started, but newer completed, and the backup proceeds anyway, ending up in a broken state. The only difference in your case is that this happens right from the first backup.
I am getting a bit suspicious that this is a significant error that happens in different cases. It looks so far that we have seen this on Dropbox and now WebDAV, perhaps also Backblaze, so it is not backend dependent.
If all you have is the single dlist file on the remote storage, could you delete that, and the local database and then run the backup again? If the same thing happens again, could you try downgrading to 2.1.0.2 and try again?
I am pretty confident that the issue is resolved for 2.1.0.108+ but it is still some time before we are at a stable 2.2 release, so if we can somehow figure out what is causing this problem, I would like to get an updated stable out.