histroy file being truncated (konsole with multiple shells context)

[Samuel Krempp <Samuel.Krempp@xxxxxxxxx>]

I noticed some people already noticed that kind of unreproduced
behaviour ("vanishing history", 
http://www.zsh.org/mla/users/2002/msg00105.html )

It's becoming very frequent for me, with 3 or 4 zsh shells inside a
konsole (kde's advanced console for those that are not familiar with
kde), and zsh history set with 
HISTSIZE=99000
SAVEHIST=90000

I get truncated $HISTFILE files from time to time, and then there are
several
$HISTFILE.<number> empty files created (with the numbers certainly being
the PIDs of the shells whose history was being written, I guess)


konsole gives the shell 1s to shut down before killing it.
So I guess zsh starts writing a new history file when shutting down, and
if it is stopped before the end, the file ends-up truncated.

Shouldn't zsh be cautious about that, and use some safe commit idiom ?
(i.e. write the new file $HISTFILE.new, then commit the swap of it with
the old $HISTFILE in an atomic way)

BTW, how does incappendhistory works ?  is the history written at each
and every command, even if it means rewriting it completely every time ?

I'm using zsh a lot, and I'd really like to be able to rely on its
history for automatically archiving complicated commands and parameter
sets, with no risk of loosing any command.

In the case of very big $HISTFILE, it seems to me the best solution to
insure all commands end-up in the $HISTFILE even in case of brutal
shutdown is for each zsh to write incremental temporary histfiles (by
plain appending), then merging them (with a safe commit method) into the
final $HISTFILE at regular intervals.
zsh can then check for these files at startup, and do the merging of any
temporary files pending from last session.

A scheme like that should be both efficient and reliable, right ?

-- 
Sam