Most users will probably use Cryptomator on top of an unreliable filesystem.
If a silent error gets introduced at the beginning of a Cryptomator encrypted file, trying to read the plaintext file will result in the whole file being junk. On a normal filesystem, only the byte range or block with the error would be affected, but Cryptomator encrypts the file as a single stream, so any error, even a single bit, will be amplified and affect the rest of the file, and Cryptomator will not even realize there is an error that it can report to the user.
Wish list:
- detect silent corruption (perhaps with a per-block checksum), notify user
- minimize damage from silent corruption (limit damage to block, not entire file)
- correct/repair silent corruption (with ECC, parity, redundancy, etc)
The reliability layer could even be a separate project, independently from Cryptomator. If there was an existing FUSE/Dokany project that provided reliability, then Cryptomator could use it to provide a reliable stack: unreliable native filesystem + reliable fs layer + Cryptomator.