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

[Paul Eggert]

Carlos O'Donell wrote:

> If we really need another non-race-free API then gnulib can provide that.

We do really need it. All existing uses of renameat2-like functionality in GNU 
applications already use the non-race-free API. But as I see it, the consensus 
is to banish this functionality to Gnulib. Since it will longer matter to Gnulib 
whether Glibc introduces renameat2, I withdraw my objection to the patch.

To help forestall likely bugs in code using Glibc renameat2, it would be helpful 
for the Glibc manual to document this issue, at least for RENAME_NOREPLACE which 
is the only reason I know anybody is calling renameat2 anyway. That is, if we're 
stuck with this API, at least we should warn users about its shortcomings. 
Perhaps the Glibc manual could point to Gnulib, as a suggestion for users who 
prefer the non-race-free functionality.

> We are not "fighting" against GNU applications
As an application writer it sure looks like a fight to me. Glibc is supplying an 
API that doesn't do what GNU apps need. So I plan to change the name of the 
Gnulib function to avoid namespace collisions, and as a result GnU apps via 
Gnulib will not use Glibc renameat2 at all. (Why should they bother? The Gnulib 
function already renames atomically using code that works on more platforms than 
Glibc does, and the Gnulib code is a tiny bit more efficient even when calling 
Glibc renameat2 would work.)

If this isn't "fighting" against GNU applications, I don't want to be around 
when a real fight occurs.

I understand the desire to support an API that guarantees atomicity, and I'm not 
arguing against that. All I'm saying is that Glibc should also support use cases 
that merely prefer instead of requiring atomicity, as these are so common in 
practice that we still haven't run into a GNU app that actually *requires* 
atomicity.