Improved encrypted backup stability

[yusf]

@nebulon in the Matrix room:

s3 implementations often have different filename/path length restrictions. Especially if backup encryption is on.

I've experienced trouble with both Spaces and Minio. Spaces becoming unresponsive (support recommended deleting it and start over 🤯). Minio can't replicate said file structure because of the Cloudron encrypted backup file naming convention.

• Can something be done to ensure better compatibility with Digital Ocean's object space offering: Spaces?
• Can the same be done regarding Minio?

[marcusquinn]

Not sure if related but I wonder if file-paths can be hashed before being encrypted so they don't go over the max length limitation?

[mehdi]

@marcusquinn said in Improved encrypted backup stability:

Not sure if related but I wonder if file-paths can be hashed before being encrypted so they don't go over the max length limitation?

Nope. It must be possible to "reverse" the encryption, to decrypt the backup when restoring. But hashing is only one-way. So there would have to be an index/dictionary/hash-table thingy in addition in order to be able to reverse the hash, which makes the whole thing much more complicated.

[girish]

Can you tell me what errors you faced with minio? Already the filenames are base64 after encryption, not sure what more we can do .

[yusf]

@girish In my case I was trying to mirror the content of a remote DO object storage to a local Minio instance. I can't recall the exact error but I remember it had to do with the handling of filenames.