New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Syncthing "Receive Encrypted" mode tries to create filenames too long for EncFS filesystem #9441
Comments
ext4 supports path components up to 255 bytes, Syncthing uses up to 200. What error are you actually seeing? |
This is the error message from the logs. It gets repeated in the logs a lot:
Folder names, paths, etc. have been redacted. The exact lengths in characters remain though (i.e., the length of |
Upon further investigation, this appears to be related to #3338. My home directory is actually an EncFS filesystem, I think. The EncFS Wikipedia suggests that the max filename length is 190 bytes:
Is there any chance that Syncthing would consider decreasing the max generated filename even further? |
Yeah, that's unfortunate. We considered the limitations we were aware of, but encfs was not one of those things. There are a couple of other design warts with how the filename encoding works that should also be fixed, but doing so requires changing how they're represented in the wire protocol and migrating the files on disk etc and is a bit cumbersome so it's not an easy fix. (Of course, your computer so you do what you want to, but it seems to me like encrypted shares and encfs do essentially the same things and layering them may not buy you much extra security. One might also have hoped that the likes of encfs had abstracted this away and not exposed the encryption overhead as an extra limitation.) I thought we had one of these issues filed already but I can't find it so this can be the "we need shorter encrypted names" issue. |
An example case where the double-encryption is beneficial is if you're using a work computer as a backup node (i.e., the boss/IT has the drive encryption keys), but you still want to back you syncthing files to it. This is roughly my case. As such, I'll leave this here as a request. |
it's potentially worse than that..... so whilst the file name may meet the "maximum" requirements allowed , it may well still break the overall constraints once the path is included...even though it's not breaking the "file name" constraints. |
That has nothing to do with Syncthing encrypted path components, which are always maximum 200 ASCII characters. |
Just for completeness: The limit is for a go string length, which is bytes. So even if it was non-ASCII with multi-byte chars here, the limit would still be correct:
|
When I setup Syncthing in "Receive Encrypted" mode, Syncthing running on the computer receiving the encrypted files tries to create files with filenames too long for the ext4 filesystem which is storing the files.
While this is partly a limitation of ext4, it would be nice if Syncthing was still able to find a workaround to avoid trying to create these files which are too long, as I don't really have a choice of another filesystem.
The text was updated successfully, but these errors were encountered: