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

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

On Sat, Jan 10, 2015 at 11:41 AM, Eli Zaretskii <eliz@gnu.org> wrote:
>> From: Patrick Palka <patrick@parcs.ath.cx>
>> Date: Sat, 10 Jan 2015 11:17:56 -0500
>> Cc: gdb-patches@sourceware.org
>>
>> On Sat, Jan 10, 2015 at 11:03 AM, Eli Zaretskii <eliz@gnu.org> wrote:
>> >> From: Patrick Palka <patrick@parcs.ath.cx>
>> >> 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..
>
> According to my testing, it's EEXIST.

Ah OK.

>
>> > 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.
>
> What would you suggest that GDB2 does instead?  I see no solution here
> that would not fail in some way.  Do you?

I would just let it fail.  It's no no big deal, just an
inconsequential change in semantics: on POSIX, the last process to
perform the rename wins the race; on Windows, the first process to
perform the rename wins the race.  Yet in either case we end up with a
more-or-less up-to-date uncorrupted history file.