This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [PATCH] Append to input history file instead of overwriting it
- From: Patrick Palka <patrick at parcs dot ath dot cx>
- To: Eli Zaretskii <eliz at gnu dot org>
- Cc: gdb-patches at sourceware dot org
- Date: Sat, 10 Jan 2015 10:48:03 -0500
- Subject: Re: [PATCH] Append to input history file instead of overwriting it
- Authentication-results: sourceware.org; auth=none
- References: <CA+C-WL8uggYL3evJ6i78A6ySnfH-kGNaLb_a0-_3yLRm_2Si6g at mail dot gmail dot com> <1420903108-24831-1-git-send-email-patrick at parcs dot ath dot cx> <83wq4u63wu dot fsf at gnu dot org>
On Sat, Jan 10, 2015 at 10:39 AM, Eli Zaretskii <eliz@gnu.org> wrote:
>> From: Patrick Palka <patrick@parcs.ath.cx>
>> Cc: Patrick Palka <patrick@parcs.ath.cx>
>> 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.