[PATCH] Add renameat2 function [BZ #17662]
Florian Weimer
fweimer@redhat.com
Thu Jul 5 15:26:00 GMT 2018
On 07/05/2018 04:24 PM, Paul Eggert wrote:
> Thanks, everything looks good, except for one nit in the NEWS patch,
> which says:
>
>> If the flags are zero, the renameat2 function is implemented using
>> renameat. If the flag is not zero and there is no kernel support for
>> renameat2, the function will fail with an errno value of EINVAL.
>
>
> If the flags are zero, renameat2 is not always implemented using
> renameat. Also,
> I found that second sentence confusing (it doesn't say what happens if
> there is kernel support). How about the following text instead?
>
> ---
>
> If the flags are zero, the renameat2 function is equivalent to renameat.
> Otherwise, it uses the renameat2 system call if kernel support is
> available, and fails with an errno value of EINVAL otherwise.
Hurd doesn't have system calls, so I'm not sure if this language is
appropriate. So I would like to use this:
* The renameat2 function has been added, a variant of the
renameat function which has a flags argument. If the flags are
zero, the renameat2 function acts like renameat. If the flag
is not zero and there is no kernel support for renameat2, the
function will fail with an errno value of EINVAL. This is
different from the existing gnulib function renameat2, which
performs a plain rename operation in case of a RENAME_NOREPLACE
flags and a non-existing destination (and therefore has a race
condition that can clobber the destination inadvertently).
Thanks,
Florian
More information about the Libc-alpha
mailing list