This is the mail archive of the
mailing list for the glibc project.
Re: [PATCH] Add renameat2 function [BZ #17662]
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.
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.)
We are not "fighting" against GNU applications
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*