Re: RFC: renameat2 emulation

[Jason Thorpe <thorpej%me.com@localhost>]

> On Sep 14, 2024, at 7:20 AM, Taylor R Campbell <campbell+netbsd-tech-kern%mumble.net@localhost> wrote:
> 
>> Date: Sat, 14 Sep 2024 16:47:01 +0530
>> From: Shiv <coderaccords%gmail.com@localhost>
>> 
>> As part of my GSoC project, me and my mentor have
>> decided to extend support for renameat2 in the compat_linux.
>> We have decided to enable support for 2 newer flags, namely
>> RENAME_NOREPLACE and RENAME_EXCHANGE.
> 
> For context, here is the Linux documentation:
> 
> https://man7.org/linux/man-pages/man2/rename.2.html
> 
>   renameat2()
>       renameat2() has an additional flags argument.  A renameat2() call
>       with a zero flags argument is equivalent to renameat().
> 
>       The flags argument is a bit mask consisting of zero or more of
>       the following flags:
> 
>       RENAME_EXCHANGE
>              Atomically exchange oldpath and newpath.  Both pathnames
>              must exist but may be of different types (e.g., one could
>              be a non-empty directory and the other a symbolic link).
> 
>       RENAME_NOREPLACE
>              Don't overwrite newpath of the rename.  Return an error if
>              newpath already exists.
> 
> How widely used are these operations in the real world?  Do important
> applications rely on them or were they invented for theoretical needs
> of test suites?

For additional context, this appears to be roughly identical to macOS’s renameatx_np(2) (and renamex_np(2), the non-at version of the call).

           RENAME_SWAP
                   On file systems that support it (see getattrlist(2)
                   VOL_CAP_INT_RENAME_SWAP), it will cause the source and
                   target to be atomically swapped.  Source and target need
                   not be of the same type, i.e. it is possible to swap a file
                   with a directory.  EINVAL is returned in case of bitwise-
                   inclusive OR with RENAME_EXCL.

           RENAME_EXCL
                   On file systems that support it (see getattrlist(2)
                   VOL_CAP_INT_RENAME_EXCL), it will cause EEXIST to be
                   returned if the destination already exists. EINVAL is
                   returned in case of bitwise-inclusive OR with RENAME_SWAP.

RENAME_SWAP is particularly useful when doing atomic directory hierarchy replacement.

macOS also has the following, which is really more related to namei processing than the rename itself, but it’s included here for completeness:

           RENAME_NOFOLLOW_ANY
                   If any symbolic links are encountered during pathname
                   resolution, an error is returned.

-- thorpej