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

[Patrick Palka <patrick@parcs.ath.cx>]

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.