From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13963 invoked by alias); 10 Jan 2015 15:48:27 -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 13947 invoked by uid 89); 10 Jan 2015 15:48:26 -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-f52.google.com Received: from mail-pa0-f52.google.com (HELO mail-pa0-f52.google.com) (209.85.220.52) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Sat, 10 Jan 2015 15:48:25 +0000 Received: by mail-pa0-f52.google.com with SMTP id eu11so24091570pac.11 for ; Sat, 10 Jan 2015 07:48:23 -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=Z8CXKEfThXAFurRYfzZuNUqTE6YrQsa89vA6O478lcM=; b=fA4siEaVazECBL5jEYEhwYQNKeKp2YO9P0g5Kb9ApRAcnruHQ6q+/z1zg80G4fwFHw bzUdHVdX44jFkQeqVy760MnA3gDGLCAZ0L4abI9zmbmIMshGdAJCV1lJkJUDW3tvMxdS Z7WVY8pomMSd6vjy7qBwlDauLJbAAxYkG0fE3PxluOOruHo8qsa0mvidsgfq/DtWxNYA Yj7tQ/ttwCJxjBmxuGY6jQIyAm5wAaahV1izOwdrtb5yPfd4icXmIty3nE81mFmbGihf rwyNAsp4NCne58an9R2GChBd9HqGKNlldvqEQFPY3ps+EatFzdZkwavnxbXNBi9sh5br m9sA== X-Gm-Message-State: ALoCoQkaRl2GGohQviA2f3JVh2cqcDOvZKjK//+OavLBZyTSUrpZEjQwsQS/Q6zIhMieE3tF+Z4P X-Received: by 10.66.65.234 with SMTP id a10mr32643052pat.120.1420904903670; Sat, 10 Jan 2015 07:48:23 -0800 (PST) MIME-Version: 1.0 Received: by 10.70.22.145 with HTTP; Sat, 10 Jan 2015 07:48:03 -0800 (PST) In-Reply-To: <83wq4u63wu.fsf@gnu.org> References: <1420903108-24831-1-git-send-email-patrick@parcs.ath.cx> <83wq4u63wu.fsf@gnu.org> From: Patrick Palka Date: Sat, 10 Jan 2015 15:48: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/msg00260.txt.bz2 On Sat, Jan 10, 2015 at 10:39 AM, Eli Zaretskii wrote: >> From: Patrick Palka >> Cc: Patrick Palka >> Date: Sat, 10 Jan 2015 10:18:28 -0500 >> >> + local_history_filename = xstrprintf ("%s.%d", history_filename, getpid ()); >> + old_chain = make_cleanup (xfree, local_history_filename); >> + >> + ret = rename (history_filename, local_history_filename); >> + if (ret < 0) >> + { >> + /* If the rename failed then either the global history file never existed >> + in the first place or another GDB process is currently appending to it >> + (and has thus temporarily renamed it). Since we can't distinguish >> + between these two cases, we have to conservatively assume the first >> + case and therefore must write out (not append) our known history to >> + our local history file and try to move it back anyway. Otherwise a >> + global history file would never get created! */ >> + write_history (local_history_filename); >> + } >> + else >> + { >> + append_history (command_count, local_history_filename); >> + history_truncate_file (local_history_filename, history_max_entries); >> + } >> + >> + ret = rename (local_history_filename, history_filename); >> + saved_errno = errno; >> + if (ret < 0) >> + warning (_("Could not rename %s to %s: error %d"), >> + local_history_filename, history_filename, saved_errno); >> + >> + do_cleanups (old_chain); > > 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)? > > Thanks.