From 08265dac9f64c5f5b239ee44fe48e13fdea8298f Mon Sep 17 00:00:00 2001 From: Christian Brauner Date: Tue, 12 May 2026 15:11:36 +0200 Subject: [PATCH] wishlist: mark `unlinkat2()` as in-progress Move "Unlinking via two file descriptors" from TODO to In-Progress next to the related `AT_EMPTY_PATH` for `unlinkat()` entry. Rename the proposed syscall in the prototype to `unlinkat2()` to match the "two file descriptors" framing. Signed-off-by: Christian Brauner (Amutable) --- README.md | 32 ++++++++++++++++---------------- 1 file changed, 16 insertions(+), 16 deletions(-) diff --git a/README.md b/README.md index 8e3452b..0b44ac4 100644 --- a/README.md +++ b/README.md @@ -195,6 +195,22 @@ mounts. around only a file descriptor without having to keep the path around to be able to unlink the file/directory. +### Unlinking via two file descriptors + +`unlinkat2(dir_fd, name, inode_fd)`: taking one file descriptor +for the directory to remove a file in, and another one referring +to the inode of the filename to remove. This call should only +succeed if the specified filename still refers to the specified +inode. + +**Use-Case:** code that operates on a well-know path that might be +shared by multiple programs that jointly manage it might want to +safely remove a filename under the guarantee it still refers to +the expected inode. As a specific example, consider lock files, +that should be cleaned up only if they still refer to the assumed +owner's instance, but leave the file in place if another process +already took over the filename. + ### `AT_EMPTY_PATH` support for `openat()` and `openat2()` To get an operable version of an `O_PATH` file descriptors, it is @@ -323,22 +339,6 @@ disk I/O. Consider implementation of a naive web browser which is pointed to `file://dev/zero`, not expecting an endless amount of data to read. -### Unlinking via two file descriptors - -`unlinkat3(dir_fd, name, inode_fd)`: taking one file descriptor -for the directory to remove a file in, and another one referring -to the inode of the filename to remove. This call should only -succeed if the specified filename still refers to the specified -inode. - -**Use-Case:** code that operates on a well-know path that might be -shared by multiple programs that jointly manage it might want to -safely remove a filename under the guarantee it still refers to -the expected inode. As a specific example, consider lock files, -that should be cleaned up only if they still refer to the assumed -owner's instance, but leave the file in place if another process -already took over the filename. - ### Determining if a mount point belongs to the current user Ability to determine if a mount point belongs to the current user