From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27065 invoked by alias); 10 Jan 2015 16:18:20 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 27052 invoked by uid 89); 10 Jan 2015 16:18:19 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.2 X-HELO: mail-pa0-f44.google.com Received: from mail-pa0-f44.google.com (HELO mail-pa0-f44.google.com) (209.85.220.44) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Sat, 10 Jan 2015 16:18:18 +0000 Received: by mail-pa0-f44.google.com with SMTP id et14so24201951pad.3 for ; Sat, 10 Jan 2015 08:18:16 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=kGyXqQNjDCtqancsSNP9JHRiXjVNJFVL6XC/aQbIsxI=; b=cvpHhbpj9Lew8PIs2mOG3iwchR013IanYJGk2f9mp7OuHwVtKVd2c8mq55b1tJgZQo lPFHkz3/MEMgYMrjALVbz6gfK/18JF4bvTjjqElte0OgyUapxppvrcGilHDTEZXHzpTE S5WlfxJmwsVcPX0ouJj86iTNyrvTD32wduqdAB+28MpCiLlLCoi1UvEklu2h4fJwsymJ XohpOGB6Z+S2lmEMaacQmUA4J0nUrbYPrknbJcoPrISYsYCWsrKRDX3p3PZcB9AFYZG7 8zWwA6DbPfSUbO8YbWKxuBms14LRufSHMl6IZem1ArxZh+P9cP0f1oaaDsfhIqF0MELf 6VqQ== X-Gm-Message-State: ALoCoQkDMci5OBQscLEAJf1lt5rlUsKutWfQXYu0JQOaGPf2vz2T+FLYgSjJYK2b/Jg6/lZlBT8N X-Received: by 10.68.194.106 with SMTP id hv10mr31903160pbc.50.1420906696427; Sat, 10 Jan 2015 08:18:16 -0800 (PST) MIME-Version: 1.0 Received: by 10.70.22.145 with HTTP; Sat, 10 Jan 2015 08:17:56 -0800 (PST) In-Reply-To: <83twzy62t5.fsf@gnu.org> References: <1420903108-24831-1-git-send-email-patrick@parcs.ath.cx> <83wq4u63wu.fsf@gnu.org> <83twzy62t5.fsf@gnu.org> From: Patrick Palka Date: Sat, 10 Jan 2015 16:18:00 -0000 Message-ID: Subject: Re: [PATCH] Append to input history file instead of overwriting it To: Eli Zaretskii Cc: gdb-patches@sourceware.org Content-Type: text/plain; charset=UTF-8 X-SW-Source: 2015-01/txt/msg00262.txt.bz2 On Sat, Jan 10, 2015 at 11:03 AM, Eli Zaretskii wrote: >> From: Patrick Palka >> Date: Sat, 10 Jan 2015 10:48:03 -0500 >> Cc: gdb-patches@sourceware.org >> >> > On Windows, a call to 'rename' fails if the destination already >> > exists. Does the logic here cope with that? >> >> Hmm, the logic does not really cope with Windows' behavior here, >> because the above warning should only get emitted for unexpected >> failures. So I suppose we should only emit the above warning if errno >> != EBUSY (perhaps only on Windows systems)? > > Why EBUSY? Just a wild guess. What would be the correct error code to check for? Looks like it would be EACCES.. > > We could also explicitly remove the target before the rename call (and > ignore any errors from that), which will make it work like on Posix > systems. I don't think that would be sufficient. In a hypothetical but plausible scenario, process GDB1 would call unlink(), process GDB2 would then call unlink(), process GDB1 would then call rename() successfully, process GDB2 would then call rename() and fail on Windows despite calling unlink() on the destination.