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

[Eli Zaretskii <eliz@gnu.org>]

> 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.

> > 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?