[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 13:47:24 -0700
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0

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.

reply via email to

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