From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 44825 invoked by alias); 4 Jul 2018 16:31:29 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-alpha-owner@sourceware.org Received: (qmail 44801 invoked by uid 89); 4 Jul 2018 16:31:28 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-1.1 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY,RCVD_IN_DNSWL_NONE autolearn=no version=3.3.2 spammy=fighting X-HELO: mail-qt0-f196.google.com Return-Path: Subject: Re: [PATCH] Add renameat2 function [BZ #17662] To: Andreas Schwab , Paul Eggert Cc: Florian Weimer , libc-alpha@sourceware.org, Gnulib bugs References: <20180630121447.E4C8643994575@oldenburg.str.redhat.com> <4a9cb334-48f4-139f-d917-457ce8ece57a@cs.ucla.edu> From: Carlos O'Donell Openpgp: preference=signencrypt Message-ID: Date: Wed, 04 Jul 2018 16:31:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-SW-Source: 2018-07/txt/msg00080.txt.bz2 On 07/04/2018 05:04 AM, Andreas Schwab wrote: > On Jul 03 2018, Paul Eggert 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. -- Cheers, Carlos.