This is the mail archive of the mailing list for the GDB project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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

> From: Patrick Palka <>
> Date: Sat, 10 Jan 2015 11:17:56 -0500
> Cc:
> On Sat, Jan 10, 2015 at 11:03 AM, Eli Zaretskii <> wrote:
> >> From: Patrick Palka <>
> >> Date: Sat, 10 Jan 2015 10:48:03 -0500
> >> Cc:
> >>
> >> > 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?

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]