From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9053 invoked from network); 18 Feb 2002 18:10:31 -0000 Received: from sunsite.dk (130.225.247.90) by ns1.primenet.com.au with SMTP; 18 Feb 2002 18:10:31 -0000 Received: (qmail 19711 invoked by alias); 18 Feb 2002 18:10:23 -0000 Mailing-List: contact zsh-workers-help@sunsite.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 16670 Received: (qmail 19696 invoked from network); 18 Feb 2002 18:10:23 -0000 Date: Mon, 18 Feb 2002 18:10:21 +0000 From: Adam Spiers To: zsh workers mailing list Subject: Re: vanishing history Message-ID: <20020218181021.A27877@corelli.new.ox.ac.uk> Reply-To: Adam Spiers Mail-Followup-To: zsh workers mailing list References: <20011128161905.A9726@corelli.new.ox.ac.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from wayned@users.sourceforge.net on Sat, Feb 16, 2002 at 01:28:25AM -0800 X-URL: http://tigerpig.org/ X-OS: RedHat Linux Sender: "Adam Spiers,,07775562717,020 88 30 30 35" [moved to zsh-workers] Wayne Davison (wayned@users.sourceforge.net) wrote: > On Wed, 28 Nov 2001, Adam Spiers wrote: > > Does anyone have any idea why my .zshhistory occasionally looses the > > vast majority of its contents? I can't reproduce it, so I can't begin > > to track down what's going on. > > I've seen this from time to time, but also have been unable to reproduce > it. In pouring over the code I did finally see one potential way that > the loss of contents could happen: if the history file is locked by > another process while we're trying to rewrite it. Here's the fix (which > causes us to just punt on the rewrite if we read nothing): > > Index: Src/hist.c > --- Src/hist.c 16 Feb 2002 09:15:07 -0000 1.39 > +++ Src/hist.c 16 Feb 2002 09:21:16 -0000 > @@ -2083,7 +2083,8 @@ > hist_ignore_all_dups |= isset(HISTSAVENODUPS); > readhistfile(fn, err, 0); > hist_ignore_all_dups = isset(HISTIGNOREALLDUPS); > - savehistfile(fn, err, 0); > + if (histlinect) > + savehistfile(fn, err, 0); > deletehashtable(histtab); > > curhist = remember_curhist; Thanks for that. I've found a way to reproduce the bug, and this patch (or at least, the combination of all cvs commits over the last few weeks) makes zsh core dump when I try that way, which is to simply type ^X?, which is bound to _complete_debug. This somehow manages to reset the history file to almost empty. I've tracked it as far as the inc_append_history option, which disabling stops the core dump. Beyond that I'm out of my depth.