From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 80236 invoked by alias); 3 Jul 2018 19:06:00 -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 80204 invoked by uid 89); 3 Jul 2018 19:05:59 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.3.2 spammy=typical, it'll X-HELO: zimbra.cs.ucla.edu Subject: Re: [PATCH] Add renameat2 function [BZ #17662] To: Florian Weimer , libc-alpha@sourceware.org Cc: Gnulib bugs References: <20180630121447.E4C8643994575@oldenburg.str.redhat.com> <4a9cb334-48f4-139f-d917-457ce8ece57a@cs.ucla.edu> From: Paul Eggert Openpgp: preference=signencrypt Message-ID: Date: Tue, 03 Jul 2018 19:06: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; format=flowed Content-Transfer-Encoding: quoted-printable X-SW-Source: 2018-07/txt/msg00064.txt.bz2 Florian Weimer wrote: > Surely that's a gnulib bug because the main reason for the RENAME_NOREPLA= CE=20 > variant renameat2 was to avoid exactly that race (or the other race where= the=20 > file exists under both the old and new path). No, it's intended behavior, not a bug. GNU mv uses renameat2 with=20 RENAME_NOREPLACE. mv wants the noreplace semantics on platforms that suppor= t it=20 (currently only recent Linux and macOS kernels); otherwise it wants exactly= that=20 race because that's the best that can be done on other platforms. If Gnulib= =20 renameat2 simply failed with EINVAL because RENAME_NOREPLACE was not suppor= ted,=20 GNU mv would simply use the same racy fallback that Gnulib renameat2 alread= y uses. Other GNU applications are similar to GNU mv in this respect. > The gnulib function should simply be called something else, not renameat2. Although Gnulib will do that if necessary, it'll be unfortunate if GNU=20 applications typically don't call glibc renameat2 directly (because it will= be=20 such a pain to use in the typical case) and use the Gnulib function instead= .=20 It'd be nicer if Glibc supported GNU applications rather than fought with t= hem,=20 and the RENAME_NONATOMIC flag I suggested would provide a more convenient a= nd=20 logical way to do that than a newly-named Gnulib function would.