From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25313 invoked by alias); 4 Jul 2018 20:26:46 -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 25297 invoked by uid 89); 4 Jul 2018 20:26:45 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy= X-HELO: mx1.redhat.com Subject: Re: [PATCH] Add renameat2 function [BZ #17662] To: Carlos O'Donell , Paul Eggert , Andreas Schwab Cc: libc-alpha@sourceware.org, Gnulib bugs References: <20180630121447.E4C8643994575@oldenburg.str.redhat.com> <4a9cb334-48f4-139f-d917-457ce8ece57a@cs.ucla.edu> <59d43024-6c94-9444-929d-03868b092b57@redhat.com> From: Florian Weimer Message-ID: <277401d5-b21d-61aa-ee9d-4417614a9656@redhat.com> Date: Wed, 04 Jul 2018 20:26: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: <59d43024-6c94-9444-929d-03868b092b57@redhat.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2018-07/txt/msg00088.txt.bz2 On 07/04/2018 10:13 PM, Carlos O'Donell wrote: > This is a good suggestion, and I think Florian should work on something > going into the manual to document the behaviour. We do not have any documentation for the *at functions at present. I find it difficult to document renameat2 without reference to openat and a generic description of the AT_* flags. I feel this is something we should tackle after the release. Once the patch is in, I will propose something for the existing manual page, documenting the EINVAL behavior of the glibc wrapper and the existence of the gnulib implementation. > You position Gnulib's implementation as having no drawbacks, but this > is not true. The API has a race, and it is something which along with > other similar racy APIs has caused difficult to solve problems a the > distribution level. And as Joseph pointed out, there is a different emulation strategy with a different failure mode (use link and potentially leave behind a hard-linked file under both names). Thanks, Florian