resolve_collision_directly(9)

πŸ“¦ version 7.3.1, in nixpkgs unstable

okay bestie, you've landed on the Kernel API Manual page for resolve_collision_directly(9) πŸ’… β€” manual name folded in near the top, exactly the vibe, and no boring copied header line in sight. This is the group-chat recap, but every single technical crumb is still here, fr fr.

πŸŽ€ NAME πŸŽ€

resolve_collision_directly β€” resolve a collision directly.


✨ SYNOPSIS ✨

int resolve_collision_directly (struct ubifs_info *c , const union
ubifs_key *key , struct ubifs_znode **zn , int *n , int lnum , int offs
);

🌸 ARGUMENTS 🌸

okay so here's the cast of characters:

  • c β€” UBIFS file-system description object
  • key β€” key of directory entry
  • zn β€” znode is passed and returned here
  • n β€” zbranch number is passed and returned here
  • lnum β€” LEB number of dent node to match
  • offs β€” offset of dent node to match

πŸ’– DESCRIPTION πŸ’–

okay so this function is for "hashed" keys β€” its whole job is making sure the found directory or extended attribute entry node is what was looked for. It's used when the flash address of the right node is already known (lnum:offs), which makes resolving collisions so much easier (no need to read entries and match full names, literally a blessing).

This function returns 1 and sets zn and n if the collision is resolved, returns 0 if lnum:offs is not found and zn and n are set to the previous directory entry. Otherwise a negative error code is returned. πŸ’…


πŸ¦‹ SEE ALSO πŸ¦‹

Kernel file ./fs/ubifs/tnc.c β€” and here's the whole iconic lineup:


mwah πŸ’‹ β€” this page came from ./fs/ubifs, dated October 2026, and it's literally resolve_collision_directly(9). periodt. 🫢

πŸ“¦ where this page comes from