start_renaming(9)
π start_renaming β like, the actual manual page
okay so this is start_renaming(9) from the Kernel API Manual (yes, section 9, kernel-land, we're fancy) and bestie, let me tell you what it does β¨
πΈ NAME πΈ
start_renaming β it looks up and locks names for rename, and it does the permission checking too π«Ά
β¨ SYNOPSIS β¨
int start_renaming (struct renamedata *rd , int lookup_flags , struct
qstr *old_last , struct qstr *new_last );
π ARGUMENTS π
rdβ the rename data, and she's carrying everything: the parents, the flags, and she's also the one who receives the found dentries on the way out πlookup_flagsβ extra flags you wanna pass along to->lookup, likeLOOKUP_REVAL,LOOKUP_NO_SYMLINKSetc. whatever your heart desires β¨old_lastβ the name of the object living inrd.old_parentnew_lastβ the name of the object living inrd.new_parent
π¦ DESCRIPTION π¦
Okay so picture this: you look up two names and then make sure the locks are actually in place for the rename. That's the whole vibe check π₯
On success, the dentries you found get stored in rd.old_dentry and rd.new_dentry. Also β important β the refcount on rd->old_parent gets increased. Those references and the lock get dropped by end_renaming, so don't you dare think you can just hang onto them, ngl.
The qstrs you pass in don't need to have the hash calculated β it's giving low-effort-on-your-end, we handle it. And basic eXecute permission checking gets performed against rd.mnt_idmap π
β RETURN β
zero, or an error. That's it, that's the whole return section π (zero means slay, anything else means go read errno)
π SEE ALSO π
This is the part where the manpage goes absolutely feral with the cross-references, and honestly? Iconic. Main character energy is the whole Kernel file ./fs/namei.c:
check_acl(9), acl_permission_check(9), generic_permission(9), do_inode_permission(9), sb_permission(9), inode_permission(9), path_get(9), path_put(9), path_connected(9), try_to_unlazy(9), try_to_unlazy_next(9), complete_walk(9), may_follow_link(9), safe_hardlink_source(9), may_linkat(9), may_create_in_sticky(9), lookup_fast(9), start_dirop(9), end_dirop(9), kern_path_parent(9), vfs_path_parent_lookup(9), vfs_path_lookup(9), try_lookup_noperm(9), lookup_noperm(9), lookup_one(9), lookup_one_unlocked(9), lookup_one_positive_killable(9), lookup_one_positive_unlocked(9), lookup_noperm_unlocked(9), start_creating(9), start_removing(9), start_creating_killable(9), start_removing_killable(9), start_creating_noperm(9), start_removing_noperm(9), start_creating_dentry(9), start_removing_dentry(9), __start_renaming(9), start_renaming_dentry(9), start_renaming_two_dentries(9), vfs_prepare_mode(9), vfs_create(9), atomic_open(9), vfs_lookup_open(9), vfs_tmpfile(9), kernel_tmpfile_open(9), end_creating_path(9), dentry_create(9), vfs_mknod(9), vfs_mkdir(9), vfs_rmdir(9), vfs_unlink(9), vfs_symlink(9), vfs_link(9), vfs_rename(9), vfs_readlink(9), vfs_get_link(9), page_get_link(9), page_put_link(9)
like, go read all of them, iykyk ππ
ngl the whole thing lives in./fsβ that's the source, and this gorgeous page is dated October 2026, versionstart_renaming(9). bye bestie, go rename something responsibly π§ββοΈπΈ
π¦ where this page comes from
- nixpkgs unstable: linux-manual 7.3.1
- π girlified by deepseek-ai/DeepSeek-V4.1-Flash-1017 on : a language model's rewrite of the original, under its terms