From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27298 invoked from network); 18 Mar 2005 17:52:00 -0000 Received: from news.dotsrc.org (HELO a.mx.sunsite.dk) (130.225.247.88) by ns1.primenet.com.au with SMTP; 18 Mar 2005 17:52:00 -0000 Received: (qmail 82323 invoked from network); 18 Mar 2005 17:51:54 -0000 Received: from sunsite.dk (130.225.247.90) by a.mx.sunsite.dk with SMTP; 18 Mar 2005 17:51:54 -0000 Received: (qmail 25213 invoked by alias); 18 Mar 2005 17:51:51 -0000 Mailing-List: contact zsh-workers-help@sunsite.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 21010 Received: (qmail 25200 invoked from network); 18 Mar 2005 17:51:51 -0000 Received: from news.dotsrc.org (HELO a.mx.sunsite.dk) (130.225.247.88) by sunsite.dk with SMTP; 18 Mar 2005 17:51:51 -0000 Received: (qmail 82044 invoked from network); 18 Mar 2005 17:51:51 -0000 Received: from dsl3-63-249-88-2.cruzio.com (HELO dot.blorf.net) (63.249.88.2) by a.mx.sunsite.dk with SMTP; 18 Mar 2005 17:51:47 -0000 Received: by dot.blorf.net (Postfix, from userid 1000) id 663CAAB5B; Fri, 18 Mar 2005 09:51:45 -0800 (PST) Date: Fri, 18 Mar 2005 09:51:45 -0800 From: Wayne Davison To: Andrey Borzenkov Cc: zsh-workers@sunsite.dk Subject: Re: revisiting history-file rewriting Message-ID: <20050318175145.GC5500@blorf.net> References: <20050316204059.GA1298@blorf.net> <20050317024919.GD13937@blorf.net> <200503181918.30617.arvidjaar@newmail.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200503181918.30617.arvidjaar@newmail.ru> User-Agent: Mutt/1.5.6+20040907i X-Spam-Checker-Version: SpamAssassin 3.0.2 on a.mx.sunsite.dk X-Spam-Level: X-Spam-Status: No, score=-2.6 required=6.0 tests=BAYES_00 autolearn=ham version=3.0.2 X-Spam-Hits: -2.6 On Fri, Mar 18, 2005 at 07:18:25PM +0300, Andrey Borzenkov wrote: > I have a bunch of [.zsh_history.XXXXXX files] > with contents like "9354 localhost.localdomain" You must manually remove them. I'm curious why you're getting a regular occurrence of them, though. Do you not use any of the history-appending options (e.g. APPEND_HISTORY or SHARE_HISTORY)? These temp files should only remain if zsh gets killed while it is waiting for the *.LOCK file, and a zsh that is appending history will not try to re-write the history file when it has received a signal telling it to die, so that usually avoids these droppings. If no history-appending option is specified, then having multiple zshs running when the system goes down does tend to cause these files to be left around. The locking algorithm has an alternate code section that avoids the creation of a temporary file, but I think that this alternative might not be good for NFS (since it relies on O_EXCL). Perhaps we should make this locking choice an option instead of conditionally compiled? This discussion reminded me of why I originally chose to use the name $HISTFILE.new instead of a unique name for rewriting the history file: it avoids extra copies of the history file lying around when zsh gets killed during the rewriting (and since this should only happen if the user does not have a history-appending option enabled, it doesn't cause the loss of any extra information that wouldn't have already been lost by the multiple zsh processes all overwriting each others history file). ..wayne..