Syncthing "Receive Encrypted" mode tries to create filenames too long for EncFS filesystem about syncthing HOT 8 OPEN

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:

Most filesystems limit filenames to 255 bytes; in that case, EncFS only supports filenames up to 190 bytes.

Is there any chance that Syncthing would consider decreasing the max generated filename even further?

it's potentially worse than that.....
you seem to be assuming the encoding is standard and not something like MBC Chinese or other Asian Characters, so potentially your path/ filename can far exceed the max for most file systems.
normally any Path name in non "English". had to be divided by 3 or 4., so if it looks like it is 10 char long, it can actually be 30 or 40 long... fortunately the filenames are machine generated, but the paths are user.
so simply checking the file name length is not enough... because you are syncing to paths.

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.

from syncthing.

That has nothing to do with Syncthing encrypted path components, which are always maximum 200 ASCII characters.

from syncthing.

ext4 supports path components up to 255 bytes, Syncthing uses up to 200. What error are you actually seeing?

from syncthing.

This is the error message from the logs. It gets repeated in the logs a lot:

2024-03-02 18:10:55 Puller (folder "1xxxxxxx" (7xxxx-12345), item "N.syncthing-enc/JK/G5B18RMND3J7CE5OJHKIFMAFKLDMI9LS81NKQ66FKRG8K34JP0K1Q5G9JIS58519S85IJLV5EI1SHM6QJ647QDA3DET1BS85JN9L45E2SCD1C538HD5LO09E1VV5KV0O8SPH44EUTT3TA9VDQL22JLNT18VNM92NUMTE028"): syncing: finishing: checking existing file: lstat /home/xxxx/1xxxxxxx/N.syncthing-enc/JK/G5B18RMND3J7CE5OJHKIFMAFKLDMI9LS81NKQ66FKRG8K34JP0K1Q5G9JIS58519S85IJLV5EI1SHM6QJ647QDA3DET1BS85JN9L45E2SCD1C538HD5LO09E1VV5KV0O8SPH44EUTT3TA9VDQL22JLNT18VNM92NUMTE028: file name too long
2024-03-02 18:10:55 "1xxxxxxx" (7xxxx-12345): Failed to sync 587 items
2024-03-02 18:10:55 Folder "1xxxxxxx" (7xxxx-12345) isn't making sync progress - retrying in 1h6m0s.

Folder names, paths, etc. have been redacted. The exact lengths in characters remain though (i.e., the length of x characters is the exact same length as the original names).

from syncthing.

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:

Most filesystems limit filenames to 255 bytes; in that case, EncFS only supports filenames up to 190 bytes.

Is there any chance that Syncthing would consider decreasing the max generated filename even further?

from syncthing.

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.

from syncthing.

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.

from syncthing.

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:

len(s) string type string length in bytes

https://go.dev/ref/spec#Length_and_capacity

from syncthing.