From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 52791 invoked by alias); 2 Jul 2018 17:38:31 -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 52381 invoked by uid 89); 2 Jul 2018 17:38:31 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00,KAM_SHORT,SPF_PASS autolearn=ham version=3.3.2 spammy=201807, apps, succeeds, gnulib X-HELO: zimbra.cs.ucla.edu Subject: Re: [PATCH] Add renameat2 function [BZ #17662] To: Florian Weimer , libc-alpha@sourceware.org References: <20180630121447.E4C8643994575@oldenburg.str.redhat.com> From: Paul Eggert Openpgp: preference=signencrypt Cc: Gnulib bugs Message-ID: <4a9cb334-48f4-139f-d917-457ce8ece57a@cs.ucla.edu> Date: Mon, 02 Jul 2018 17:38: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: <20180630121447.E4C8643994575@oldenburg.str.redhat.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable X-SW-Source: 2018-07/txt/msg00036.txt.bz2 Florian Weimer wrote: > Without kernel support, a non-zero argument returns EINVAL, not ENOSYS. > This mirrors what the kernel does for invalid renameat2 flags. The Gnulib renameat2 function=20 has=20 different semantics with non-zero flags. On GNU/Linux if flags=3D=3DRENAME_= NOREPLACE=20 and the Linux syscall fails due to EINVAL/ENOSYS/ENOTSUP, Gnulib renameat2 = falls=20 back on fstatatting the destination, failing if fstatat succeeds, and using= =20 ordinary renameat otherwise. Of course this implementation has a race condi= tion,=20 but Gnulib-using applications like GNU 'mv' prefer this implementation sinc= e if=20 the kernel doesn't support RENAME_NOREPLACE they'd just fall back on fstata= t=20 themselves anyway, if renameat2 didn't do that for them. It strikes me that this will be a common use case for RENAME_NOREPLACE in o= ther=20 glibc applications too, perhaps the most common one. In that case, perhaps = glibc=20 should support the Gnulib semantics, by falling back on a non-atomic=20 implementation of RENAME_NOREPLACE if the kernel doesn't support the atomic= one.=20 If that's too drastic, how about having glibc support a new flag=20 RENAME_NOREPLACE_NONATOMIC that works on all platforms? We could of course = add=20 such a flag to Gnulib, but I expect it'd be better if the functionality wer= e=20 available to all Glibc programs, not just to Gnulib-using programs. PS. In Gnulib-using apps we've found no need for RENAME_EXCHANGE or=20 RENAME_WHITEOUT and so Gnulib does not implement them on older GNU/Linux=20 kernels. Gnulib renameat2 does support RENAME_EXCHANGE on macOS since it's = easy=20 there. [CC:ing this to bug-gnulib; for those joining in, a recent email in this th= read=20 is here: https://sourceware.org/ml/libc-alpha/2018-07/msg00003.html ]