[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