UNLINK(2)

💅 UNLINK(2) — the manual page, bestie edition

okay so. you're in section 2 of the system calls manual (that's the System Calls Manual bestie, kernel territory 👑) and the page is called UNLINK. two functions, one glow-up: unlink and unlinkat. it's giving "delete but make it a syscall." let's GO 🦋

---

✨ NAME ✨

unlink, unlinkat — remove directory entry

📚 LIBRARY 📚

Standard C Library (libc, -lc) — yeah yeah, link the C library, you know the drill 🎀

🧚 SYNOPSIS 🧚

#include <unistd.h>

int
unlink(const char *path);

int
unlinkat(int fd, const char *path, int flag);

🌸 DESCRIPTION 🌸

so the unlink() system call removes the link named by path from its directory, and then decrements the link count of the file that was referenced by that link. no cap. and here's the tea: if that decrement drops the link count of the file all the way down to zero, and literally no process has the file open? then all the resources associated with that file get reclaimed. bye girl 💀

but if one or more processes still have the file open when the last link gets removed, the link is removed, but the actual removal of the file is delayed until all references to it have been closed. it's lowkey just vibing in limbo until everyone lets go 🫶

also — huge — the path argument may not be a directory. not the move, babe.

now unlinkat(). it's equivalent to unlink() or rmdir(), EXCEPT when path specifies a relative path. in that case, the directory entry to be removed is determined relative to the directory associated with the file descriptor fd — instead of relative to the current working directory. main character energy: it's like saying "not from here, from there" 💅

the values for flag are constructed by a bitwise-inclusive OR of flags from this list, defined in <fcntl.h>:

AT_REMOVEDIR

remove the directory entry specified by fd and path as a directory, not a normal file. okay so it's rmdir mode, got it.

---

and if unlinkat() gets passed the special value AT_FDCWD in the fd parameter, the current working directory is used, and the behavior is identical to a call to unlink or rmdir respectively — depending on whether or not the AT_REMOVEDIR bit is set in flag. cute, right? ✨

🎀 RETURN VALUES 🎀

the unlink() function returns the value 0 if successful 🥳 otherwise the value -1 is returned and the global variable errno is set to indicate the error. classic.

💀 ERRORS 💀

the unlink() succeeds unless:

• [ENOTDIR] — a component of the path prefix is not a directory. 🚫
• [EISDIR] — the named file is a directory. girl that's a folder.
• [ENAMETOOLONG] — a component of a pathname exceeded 255 characters, or an entire path name exceeded 1023 characters. that's so long babe, chill.
• [ENOENT] — the named file does not exist. it's not there. it never was. 🙈
• [EACCES] — search permission is denied for a component of the path prefix.
• [EACCES] — write permission is denied on the directory containing the link to be removed.
• [ELOOP] — too many symbolic links were encountered in translating the pathname. infinite loop vibes, absolutely not 🌀
• [EPERM] — the named file is a directory.
• [EPERM] — the named file has its immutable, undeletable or append-only flag set. see the chflags(2) manual page for more info, iykyk.
• [EPERM] — the parent directory of the named file has its immutable or append-only flag set.
• [EPERM] — the directory containing the file is marked sticky, and neither the containing directory nor the file to be removed are owned by the effective user ID. sticky directory says hands OFF ✋
• [EIO] — an I/O error occurred while deleting the directory entry or deallocating the inode. yikes.
• [EINTEGRITY] — corrupted data was detected while reading from the file system. that's cursed, fr fr.
• [EROFS] — the named file resides on a read-only file system. read. only. no touchy.
• [EFAULT] — the path argument points outside the process's allocated address space. that pointer is somewhere it should not be 👀
• [ENOSPC] — on file systems supporting copy-on-write or snapshots, there was not enough free space to record metadata for the delete operation of the file. deleting needs space, the plot twist 🍓

---

and in addition to the errors returned by the unlink(), the unlinkat() may fail if:

• [EBADF] — the path argument does not specify an absolute path and the fd argument is neither AT_FDCWD nor a valid file descriptor open for searching.
• [ENOTEMPTY] — the flag parameter has the AT_REMOVEDIR bit set and the path argument names a directory that is not an empty directory, or there are hard links to the directory other than dot or a single entry in dot-dot. empty it out first bestie, i don't make the rules.
• [ENOTDIR] — the flag parameter has the AT_REMOVEDIR bit set and path does not name a directory.
• [EINVAL] — the value of the flag argument is not valid. that flag? fake. not real. 💀
• [ENOTDIR] — the path argument is not an absolute path and fd is neither AT_FDCWD nor a file descriptor associated with a directory.

ok real talk, the list is long but it's all "you asked for something the kernel can't give you." read the bracket, fix the thing, move on. periodt. 👑

👀 SEE ALSO 👀

chflags(2), close(2), link(2), rmdir(2), symlink(7)

📜 STANDARDS 📜

the unlinkat() system call follows The Open Group Extended API Set 2 specification. she's certified ✨

🕰️ HISTORY 🕰️

the unlink() function appeared in Version 1 AT&T UNIX. yes, Version 1. ancient. iconic. a true original 👑

the unlinkat() system call appeared in FreeBSD 8.0.

and here's a lil lore drop: the unlink() system call traditionally allows the super-user to unlink directories, which can damage the file system integrity. 😭 this implementation no longer permits it. so if you were hoping to speedrun filesystem corruption as root — no. absolutely not. the door is closed, we don't do that anymore 🙅‍♀️

---

k bye bestie, go delete something responsibly 🫶 this page is from the Debian crew, dated March 30, 2020 — mwah 💋