Re: [PATCH] Add renameat2 function [BZ #17662]

[Paul Eggert]

Carlos O'Donell wrote:
> On 07/04/2018 03:35 PM, Paul Eggert wrote:

> You position Gnulib's implementation as having no drawbacks

That certainly was not my intent. The Gnulib implementation has known race 
conditions on platforms whose kernels don't promise atomicity. It's just that 
Gnulib-using applications prefer this drawback to implementing racy subsititutes 
themselves.

Not every racy API is a bug. (If it were, we'd have to abolish stdio. :-)

> I have no objection to a racy API with another name.

Yes, that is direction we're heading.

> > we still haven't
> > run into a GNU app that actually *requires* atomicity.
>
> coreutils *requires* it to solve the race

Sure, but Coreutils doesn't *require* atomicity to build and run just as well 
has it has run for decades. All Coreutils *requires* is the Gnulib API, which 
says "we'll try to avoid the race if we can". So far, GNU applications needing 
renameat2-like functionality have all fallen into the Coreutils camp.

> I would like *coretuils* itself to make the decision
> in their sources, with full disclosure,

Coreutils already does that. Coreutils uses Gnulib, which is a source-code 
library. Coreutils tarballs contain a copy of the source code that embody this 
decision and fully disclose it. And if Glibc added an API that supported 
Coreutils-like functionality here, programs using this new API would also be 
making the decision with full disclosure. So we should be OK here.