From my understanding of the Untrusted (Encrypted) Devices documentation, the encrypted filenames will be a couple hundred characters long. This will cause problems on machines with shorter filename limits, for example ecryptfs/Synology has a limit of 143 Latin characters. Please consider the impact on users of such machines in the design of this feature, thanks.
Our current max path component is 200 characters. There’s no technical reason not to have it slightly shorter, other than the fact that it breaks existing setups. That said, having encrypted folders on top of an arguably broken filesystem that adds another layer of encryption doesn’t seem like a very compelling use case…
3 Likes
Great to hear that this could be achievable. Agreed that the limitations of such filesystems are annoying, though unfortunately they are not rare. The use case would be eg. syncing a folder to another person or company’s (untrusted) NAS, where the NAS owner has enabled ecryptfs and does not want to make any exceptions. It seems this would be a relatively common circumstance, considering the popularity of Synology and other systems where ecryptfs is the only supported encryption scheme.
But that’s the whole point, that you don’t need to use an encryption scheme if it’s already encrypted in syncthing.
From a technical standpoint that is absolutely correct, I agree. I would just like to point out that, reality being what it is, one does not always have the ability/permission to modify a setup and carve out an exception to the preexisting filesystem encryption, despite how logical it may be in theory. It would be unfortunate to be unable to use this great feature for such reasons, so hopefully the feature will be designed for compatibility with the many devices that use such filesystems.