fscrypt_fnam...crypted_size(9)

πŸ“¦ version 7.3.1, in nixpkgs unstable

πŸŽ€ fscrypt_fname_encrypted_size(9) πŸŽ€

okay bestie so this is a page from the Kernel API Manual β€” specifically the entry for fscrypt_fname_encrypted_size, and ngl it's a little cutie that does exactly one job and does it slayfully ✨


🌸 NAME 🌸

fscrypt_fname_encrypted_size β€” literally just calculates the length of an encrypted filename πŸ’…


πŸ¦‹ SYNOPSIS πŸ¦‹

bool fscrypt_fname_encrypted_size(const struct inode *inode, u32 orig_len,
                                  u32 max_len, u32 *encrypted_len_ret);

✨ ARGUMENTS ✨

  • inode β€” the parent inode of the dentry name being encrypted. heads up bestie, the key must already be set up before you call this πŸ”‘
  • orig_len β€” the length of the original filename, the pre-glow-up version πŸ’–
  • max_len β€” the maximum length this function is allowed to return. it's the vibe ceiling, fr fr
  • encrypted_len_ret β€” where the calculated length gets returned (on success). it's giving "out-parameter main character energy" πŸ‘‘

πŸ’œ DESCRIPTION πŸ’œ

so here's the tea 🍡 β€” filenames that are shorter than the maximum length may have their lengths increased slightly by encryption. why? because of padding that gets applied. that's it, that's the whole thing. the padding is the reason, not me 🌸


πŸ”₯ RETURN πŸ”₯

  • false if orig_len is greater than max_len 😭 (too long, no thank you)
  • otherwise true, and encrypted_len_ret gets filled out with the length (up to max_len) βœ…
like, it literally cannot go over max_len, that's the whole boundary check. respect the boundary 🫢

🌈 SEE ALSO 🌈

kernel file ./fs/crypto/fname.c plus the whole friend group:


and that's the whole page bestie, no crumbs left πŸ“ this one lives in ./fs/crypto, from October 2026, in the Kernel API Manual β€” mwah, go encrypt some filenames responsibly πŸ’–βœ¨πŸŽ€

πŸ“¦ where this page comes from