Re: The HIST_EXPIRE_DUPS_FIRST might corrupt and wipe partially history file if many shells exit at the same time

[Piotr Karbowski <piotr.karbowski@xxxxxxxxxxxxx>]

Hi,

On 19/03/2023 22.01, Bart Schaefer wrote:
> On Sun, Mar 19, 2023 at 11:38 AM Piotr Karbowski
> <piotr.karbowski@xxxxxxxxxxxxx> wrote:
>>
>> The HIST_SAVE_BY_COPY does not seems to be enabled and I am unable to
>> enable it.
>
> "setopt" with no arguments shows you only the options that differ from
> the defaults.  So if HIST_SAVE_BY_COPY does not show up, it IS
> enabled.
>
> Use "set -o" (with no other arguments) to see the full set of options
> and on/off status, or "setopt kshoptionprint" before running "setopt"
> alone.
>
> If an option shows up with a  "no" prefix in unsetopt output, that
> means it is on.  There is no third state.

That make sense, thanks. The 'set -o' do confirm 'nohistsavebycopy off'

I looked around in Src/hist.c where it does the copy history and indeed
it does use O_EXCL so this it does the locking.

I still did lost few thousands lines from the end of .zsh_history
yesterday again when I git a bug with openbox+glib-2.76.0 that crashed
entire of my X session, with many urxvt and zsh there and i had to
restore it from hourly borgbackup.

With this, I do not know where this problem originates from but I do see
that I am not the only one and the stackoverflow user with MacOS do hit
this problem as well.

Anything else I could provide to help norrowing it down?

-- Piotr.