Hello Tyler and every body, I guess those who suggested compressing the filename meant for it to take place before encrypting the filename, when there's still reasonable redundancy in it, not after encryption and before encoding.
I like both ideas of the storage in file header and in xattr. I guess the hit on performance should be the determinant of which is more feasible, and I'm slightly favourable of xattr. If such choice is made, then I think making the process uniformal is sounder on the long term, even though it will be a hassle for current users of eCryptfs - like me - who will have to recreate their encrypted storage. By uniformal I mean there shouldn't be a check of whether the name is short enough and as such is to be found in the underlying filesystem, or longer than the threshold and thus is stored elsewhere. This will make the next version of eCryptfs incompatible with the previous. Yeah, radical but better now than bloat, in my opinion. Lastly, regarding the name to leave in the underlying filesystem, I guess the encoded cryptographic hash of the encrypted filename should be far within the length limit, while almost globally unique. I've hit this the first day I upgraded to 10.04 using eCryptfs over ext4, almost 6 months ago. Thank you for your efforts, Tyler. I'm interested to know the direction the solution is heading. Regards, -- file name to long when creating new file (ecryptfs_lookup: lookup_one_len() returned [-36] on lower_dentry) https://bugs.launchpad.net/bugs/344878 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
