Re: [PATCH] Append to input history file instead of overwriting it

Patrick Palka
2015-01-10T15:48:27Z

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.