This is the mail archive of the
mailing list for the GDB project.
Re: [PATCH] Append to input history file instead of overwriting it
- From: Patrick Palka <patrick at parcs dot ath dot cx>
- To: Eli Zaretskii <eliz at gnu dot org>
- Cc: gdb-patches at sourceware dot org
- Date: Sat, 10 Jan 2015 13:16:45 -0500
- Subject: Re: [PATCH] Append to input history file instead of overwriting it
- Authentication-results: sourceware.org; auth=none
- References: <CA+C-WL8uggYL3evJ6i78A6ySnfH-kGNaLb_a0-_3yLRm_2Si6g at mail dot gmail dot com> <1420903108-24831-1-git-send-email-patrick at parcs dot ath dot cx> <83wq4u63wu dot fsf at gnu dot org> <CA+C-WL88pk1tnTHp1FS_LMhNXiypmWify75d2eJW4w+2aLjRTA at mail dot gmail dot com> <83twzy62t5 dot fsf at gnu dot org> <CA+C-WL-E-vAXHCik8jLk9A-4E40tLLagkiNfo7nCPsbsU07gcQ at mail dot gmail dot com> <83sifi611j dot fsf at gnu dot org>
On Sat, Jan 10, 2015 at 11:41 AM, Eli Zaretskii <firstname.lastname@example.org> wrote:
>> From: Patrick Palka <email@example.com>
>> Date: Sat, 10 Jan 2015 11:17:56 -0500
>> Cc: firstname.lastname@example.org
>> On Sat, Jan 10, 2015 at 11:03 AM, Eli Zaretskii <email@example.com> wrote:
>> >> From: Patrick Palka <firstname.lastname@example.org>
>> >> Date: Sat, 10 Jan 2015 10:48:03 -0500
>> >> Cc: email@example.com
>> >> > 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?
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.