Re: histroy file being truncated (konsole with multiple shells context)

[Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>]

[Further discussion should probably move to zsh-workers.]

On Wed, 29 Sep 2004, Wayne Davison wrote:

> The current scheme uses a lock file to ensure that only one shell at a
> time can write out the history file, but the file is updated in place,
> so it is possible for it to be truncated if zsh is killed during this
> update.

We could do something sneaky like fork a child with most signals blocked 
that does nothing but write the history file and exit, while the parent 
exits immediately to fake out _its_ parent.  That's not a very resource- 
friendly idea, though, because (among other things) it might fail due to 
inability to fork.  However, it's probably the only one that covers all 
cases short of catastrophe.

> Updating a .new file and then moving it into place would be a safer way 
> to ensure that the history file never gets truncated.

On the other hand, in that case the changes get lost entirely, which might
be just as confusing.

> ... the INC_APPEND_HISTORY and SHARE_HISTORY add new lines onto the end
> of the history file via a normal appending write.  When the file gets to
> be a certain percent larger than its configured size, it gets rewritten
> to bring its size back down.

So a signal in the middle of that rewrite would still be an issue, even if
we change the exit-time behavior.