Zsh Mailing List Archive
Messages sorted by: Reverse Date, Date, Thread, Author

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

[I had meant to comment on this earlier and forgot.]

On Sun, Jul 04, 2004 at 12:40:10PM +0200, Samuel Krempp wrote:
> 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.

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

> 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)

Updating a .new file and then moving it into place would be a safer way
to ensure that the history file never gets truncated.  I would worry a
little about compatibility changes, such as the breaking of hard-links
to the history file, so this is something that we should discuss and
consider the side effects.

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

No, 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.

I think the easiest improvement would be for zsh to avoid doing a
history-file rewrite when performing an exit due to a signal.  With an
incremental-append, zsh wouldn't have to do any history updating on
abnormal exit (making it very safe).  For those that use the more basic
APPEND_HISTORY setting, each shell would just append their history lines
and leave the history file too big (it could then be resized on load).
For those that don't use an appending-history setting, I suppose we'd
just leave their algorithm alone for now.


Messages sorted by: Reverse Date, Date, Thread, Author