zsh-users
 help / color / mirror / code / Atom feed
From: Wayne Davison <wayned@users.sourceforge.net>
To: Samuel Krempp <Samuel.Krempp@crans.org>
Cc: zsh-users@sunsite.dk
Subject: Re: histroy file being truncated (konsole with multiple shells context)
Date: Wed, 29 Sep 2004 16:03:27 -0700	[thread overview]
Message-ID: <20040929230327.GC7866@blorf.net> (raw)
In-Reply-To: <1088937610.4949.41.camel@marvin.localdomain>

[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
update.

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

..wayne..


  parent reply	other threads:[~2004-09-29 23:05 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-07-04 10:40 Samuel Krempp
2004-07-04 17:22 ` Peter Stephenson
2004-09-29 23:03 ` Wayne Davison [this message]
2004-09-30  4:39   ` Bart Schaefer
2004-09-30  8:35     ` history " Samuel Krempp

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20040929230327.GC7866@blorf.net \
    --to=wayned@users.sourceforge.net \
    --cc=Samuel.Krempp@crans.org \
    --cc=zsh-users@sunsite.dk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/zsh/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).