updated to v1.14.3 (build: 10140300) on debian 13 - flatpak.
I am using E2EE and though I checked using precisely the same setting most of the files remain encrypted. Any ideas?
Hi @JuergenHH, Thanks for your comment.
Files created by Mount/Sync in a 1.14.0 release were accidentally encrypted twice. Media backup, file/folder standard (and drag&drop) upload weren't affected.
This was patched in the 1.14.3 release, but entries created since: 1.14.0 remain unreadable and need to be deleted.
Are you referring to files uploaded recently which may be affected by the issue I've just mentioned or perhaps your files were uploaded in a distant past?(edited)
Thanks for your answer. Seems to be in connection with this. I have gained propper access. But I now remain with a lot of deleted files I have trouble to get rid of.
JuergenHH
Thanks for your answer. Seems to be in connection with this. I have gained propper access. But I now remain with a lot of deleted files I have trouble to get rid of.
But I now remain with a lot of deleted files I have trouble to get rid of.
If you have versioning enabled, then in the Trash section there is an option to delete all deleted files, which should help you to clean up any leftovers.
This obviously assumes that these couple root folders with "obfuscated" names were deleted prior to that (hence moved to Trash).(edited)
It‘s done this way. What I cannot see whether it is a problem of cubbit or S3Drive that the emptying of the trash never removes all files. Trying to remove selected files manually succeeded mostly only after second attempt.
JuergenHH
It‘s done this way. What I cannot see whether it is a problem of cubbit or S3Drive that the emptying of the trash never removes all files. Trying to remove selected files manually succeeded mostly only after second attempt.
Internally we use bulk delete API: https://docs.aws.amazon.com/AmazonS3/latest/userguide/delete-multiple-objects.html
We know that some endpoints don't necessarily report any errors when this operation fails fully or partially. Not that I am blaming Cubbit, but certainly we're going to check error handling (regarding delete) on our end.
