Zsh Mailing List Archive
Messages sorted by:
Re: histroy file being truncated (konsole with multiple shells context)
- X-seq: zsh-users 8035
- From: Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>
- To: Wayne Davison <wayned@xxxxxxxxxxxxxxxxxxxxx>
- Subject: Re: histroy file being truncated (konsole with multiple shells context)
- Date: Wed, 29 Sep 2004 21:39:24 -0700 (PDT)
- Cc: Samuel Krempp <Samuel.Krempp@xxxxxxxxx>, zsh-users@xxxxxxxxxx
- In-reply-to: <20040929230327.GC7866@xxxxxxxxx>
- Mailing-list: contact zsh-users-help@xxxxxxxxxx; run by ezmlm
- References: <1088937610.4949.41.camel@xxxxxxxxxxxxxxxxxx> <20040929230327.GC7866@xxxxxxxxx>
- Reply-to: zsh-workers@xxxxxxxxxx
[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
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.
Messages sorted by: