From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21675 invoked from network); 30 Sep 2004 04:41:20 -0000 Received: from news.dotsrc.org (HELO a.mx.sunsite.dk) (130.225.247.88) by ns1.primenet.com.au with SMTP; 30 Sep 2004 04:41:20 -0000 Received: (qmail 78964 invoked from network); 30 Sep 2004 04:41:14 -0000 Received: from sunsite.dk (130.225.247.90) by a.mx.sunsite.dk with SMTP; 30 Sep 2004 04:41:14 -0000 Received: (qmail 9816 invoked by alias); 30 Sep 2004 04:40:30 -0000 Mailing-List: contact zsh-users-help@sunsite.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 8035 Received: (qmail 9800 invoked from network); 30 Sep 2004 04:40:29 -0000 Received: from unknown (HELO a.mx.sunsite.dk) (130.225.247.88) by sunsite.dk with SMTP; 30 Sep 2004 04:40:29 -0000 Received: (qmail 77710 invoked from network); 30 Sep 2004 04:39:30 -0000 Received: from moonbase.zanshin.com (64.84.47.139) by a.mx.sunsite.dk with SMTP; 30 Sep 2004 04:39:28 -0000 Received: from toltec.zanshin.com (toltec.zanshin.com [64.84.47.166]) by moonbase.zanshin.com (8.13.1/8.13.1) with ESMTP id i8U4dO6s022483; Wed, 29 Sep 2004 21:39:24 -0700 Date: Wed, 29 Sep 2004 21:39:24 -0700 (PDT) From: Bart Schaefer Reply-To: zsh-workers@sunsite.dk To: Wayne Davison cc: Samuel Krempp , zsh-users@sunsite.dk Subject: Re: histroy file being truncated (konsole with multiple shells context) In-Reply-To: <20040929230327.GC7866@blorf.net> Message-ID: References: <1088937610.4949.41.camel@marvin.localdomain> <20040929230327.GC7866@blorf.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 on a.mx.sunsite.dk X-Spam-Level: X-Spam-Status: No, hits=0.0 required=6.0 tests=none autolearn=no version=2.63 X-Spam-Hits: 0.0 [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.