Skip to main content
16 events
when toggle format what by license comment
Jul 15, 2024 at 15:19 comment added Jay M Suggestion: Most recent fs have mechanisms for user extended attributes, and these work like a filesystem, so perhaps for encrypted file systems that have extended attributes we could simply bury the real file name in an extended attribute and then turn the path into a key. e.g. /my/very/long/path/with/<my_very_long_name> would be /enc/xxx/yy/zzz/aa/bbb/ccc/12fbn239012h293429 and be a hardlink to the real file and have an extended attribute _enc_fs_virtual_path with the real name?
Jul 4, 2022 at 19:59 comment added Paul Note that the total length (4096 max) must include space for a “null” at the end of a string, therefore the total length of a path can be no more than 4095 characters.
Jan 21, 2022 at 8:09 comment added Déjà vu Great answer, and thank you for ecryptfs.
Nov 28, 2021 at 18:57 history edited tshepang CC BY-SA 4.0
redundant
Mar 12, 2020 at 16:49 comment added Michael is it possible to specify a different prefix besides "ECRYPTFS_FNEK_ENCRYPTED"?
Sep 1, 2019 at 9:51 comment added ssokolow and a maximum path of 4096 characters is incorrect. PATH_MAX is just the maximum length for certain libc functions which can be worked around. There is no hard limit.
Jun 13, 2019 at 7:08 comment added Gabriel Staples You say eCryptfs "can optionally encrypt (obscure) filenames (or not)." How do I disable file name encryption so I can get my full 255-char file names back instead of being limited to 143 chars? I believe the way I got eCryptfs installed, by the way, was by checking the box or whatever for "Encrypted home directory" during my Ubuntu install process.
Jun 13, 2019 at 6:46 comment added Gabriel Staples So, the file name length limit for an eCryptfs-encrypted ext4 file system is 143 characters. Got it. I've used this answer to prove that conclusively via a test on my system, and this answer to even determine my file system was eCryptfs-encrytped in the first place. Then, a Google search using that info led me to this answer.
Jan 7, 2019 at 4:41 review Suggested edits
Jan 7, 2019 at 10:10
Sep 14, 2018 at 1:07 comment added Hakanai My suggestion would have been to store whatever metadata you're storing in the xattrs, instead of in the filename. :|
Dec 9, 2016 at 23:52 comment added Dale Mahalko Suggestion to developer: Split encrypted names across subdirectories that are hidden from the end user to get the necessary length, potentially even exceeding the linux max name length limit if an external filesystem needs it. A single file or directory becomes "ENCRYPTFS-01-OF-04[.....]/ENCRYPTFS-02-OF-04[.....]/ENCRYPTFS-03-OF-04[.....]/ENCRYPTFS-04-OF-04[.....]" -- Linux btrfs, ext1-4, and others have no max defined directory depth so the filesystem can handle expanding file and dir names across multiple unexposed subdirectories like this.
May 30, 2016 at 19:31 comment added Rahly This answer is not entirely correct. The max size of a filename is 255 Bytes or C/C++ char types. But the max characters in a filename vary. When using UTF-8 which is the default for most systems, the filename can be between 63-255 characters (aka Code Points), if using UTF-16, 63-127. Its important to note, that 1 character can be one or more bytes in storage space and depends on the code set that the user of the system is using.
May 14, 2016 at 15:15 comment added Grzegorz Wierzowiecki I would really love to see, FUSE overlay filesystem that resolves on it's own "too long filenames" and rest just proxy 1:1 with underlaying filesystem. Such FUSE fs would be usefull for different filesystems (ecryptfs, EncFS), while for currently supported filenames would change nothing. And again, would be optional. - My wish: unix.stackexchange.com/q/283149/9689
Mar 1, 2012 at 16:51 history edited Dustin Kirkland CC BY-SA 3.0
update limits more precisely, per tyhick's feedback
Feb 27, 2012 at 15:18 review Suggested edits
Feb 27, 2012 at 19:45
Feb 27, 2012 at 15:05 history answered Dustin Kirkland CC BY-SA 3.0