[Top][All Lists]

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

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

From: Carlos O'Donell
Subject: Re: [PATCH] Add renameat2 function [BZ #17662]
Date: Wed, 4 Jul 2018 12:31:22 -0400
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0

On 07/04/2018 05:04 AM, Andreas Schwab wrote:
> On Jul 03 2018, Paul Eggert <address@hidden> wrote:
>> Florian Weimer wrote:
>>> Surely that's a gnulib bug because the main reason for the
>>> RENAME_NOREPLACE variant renameat2 was to avoid exactly that race (or
>>> the other race where the file exists under both the old and new path).
>> No, it's intended behavior, not a bug. GNU mv uses renameat2 with
>> RENAME_NOREPLACE. mv wants the noreplace semantics on platforms that
>> support it (currently only recent Linux and macOS kernels); otherwise it
>> wants exactly that race because that's the best that can be done on other
>> platforms. If Gnulib renameat2 simply failed with EINVAL because
>> RENAME_NOREPLACE was not supported, GNU mv would simply use the same racy
>> fallback that Gnulib renameat2 already uses.
>> Other GNU applications are similar to GNU mv in this respect.
> IMHO we should not repeat the pselect error.  Glibc should provide the
> race-free guarantee that RENAME_NOREPLACE gives, so that programs that
> need it can use it without fear.

I agree completely. We are not "fighting" against GNU applications, what
we are doing is providing a set of reliable semantics.

The API should be split into 2, one symbol which provides reliable race-free
semantics, and another which doesn't. Application authors should make the
choice at the source level. In this case renameat2 is the reliable race-free
name for the operation. If we really need another non-race-free API then
gnulib can provide that.


reply via email to

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