[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Paul Eggert
Subject: Re: [PATCH] Add renameat2 function [BZ #17662]
Date: Wed, 4 Jul 2018 12:35:58 -0700
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0

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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]