[PATCH] Add renameat2 function [BZ #17662]

[Florian Weimer]

On 07/04/2018 09:53 PM, Paul Eggert wrote:
> Carlos O'Donell wrote:
> 
>> Suggest something like this:
>>
>> * The library now implements the renameat2 function. On Linux systems 
>> that
>> Â Â  support the renameat2 system call this is a wrapper for the kernel 
>> support
>> Â Â  and avoids the race conditions present with renameat. No emulation 
>> is provide
>> Â Â  and if renameat2 is not supported by the underlying operating 
>> system either
>> Â Â  an errno of ENOSYS or EINVAL error will be returned.
> 
> This wording doesn't look right, since there is emulation in some cases 
> even when renameat2 is not supported by the underlying operating system. 
> That is, when FLAGS == 0, renameat2 is often emulated via renameat.  How 
> about something like this wording instead?
> 
> * The library now implements the renameat2 function.  On Linux systems that
>  Â  support the renameat2 system call this is a wrapper for kernel support
>  Â  and when renameat2's flags are nonzero this should avoid race conditions
>    present with renameat.  The renameat2 function fails with an errno of
>  Â  ENOSYS or EINVAL when given nonzero flags that cannot be implemented
>  Â  atomically by the kernel.

I don't think the current renameat2 fallback code in glibc can return 
ENOSYS.  The generic renameat, which returns ENOSYS, is overriden by 
Linux and Hurd.

Thanks,
Florian