From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16176 invoked from network); 18 Oct 2004 00:22:34 -0000 Received: from news.dotsrc.org (HELO a.mx.sunsite.dk) (130.225.247.88) by ns1.primenet.com.au with SMTP; 18 Oct 2004 00:22:34 -0000 Received: (qmail 7974 invoked from network); 18 Oct 2004 00:22:25 -0000 Received: from sunsite.dk (130.225.247.90) by a.mx.sunsite.dk with SMTP; 18 Oct 2004 00:22:25 -0000 Received: (qmail 2649 invoked by alias); 18 Oct 2004 00:22:22 -0000 Mailing-List: contact zsh-workers-help@sunsite.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 20497 Received: (qmail 2635 invoked from network); 18 Oct 2004 00:22:21 -0000 Received: from unknown (HELO a.mx.sunsite.dk) (130.225.247.88) by sunsite.dk with SMTP; 18 Oct 2004 00:22:21 -0000 Received: (qmail 6234 invoked from network); 18 Oct 2004 00:21:22 -0000 Received: from moonbase.zanshin.com (64.84.47.139) by a.mx.sunsite.dk with SMTP; 18 Oct 2004 00:21:20 -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 i9I0LIgX031229 for ; Sun, 17 Oct 2004 17:21:18 -0700 Date: Sun, 17 Oct 2004 17:21:18 -0700 (PDT) From: Bart Schaefer Reply-To: zsh-workers@sunsite.dk To: zsh-workers@sunsite.dk Subject: Re: skip rewriting history if exiting due to signal In-Reply-To: <20041017194842.GA26158@blorf.net> Message-ID: References: <20041001193658.GD26529@blorf.net> <20041017194842.GA26158@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 On Sun, 17 Oct 2004, Wayne Davison wrote: > Here's a patch that makes the savehistfile() function use a temporary > file whenever it writes out the whole file from the start (rather than > overwriting the existing file). This could be controversial if someone > out there has a symlink for their history file Hm. - It requires a writable directory rather than merely a writable histfile. Perhaps fall back to the old behavior if the directory is not writable? Similarly, perhaps detect when the histfile is a symlink and fall back? - You haven't tested for failure of unlink() [though I'm not sure what the response to such failure would be ... except see below about O_EXCL]. - You haven't tested for failure of rename() -- and note that rename() may falsely report failure in the event of certain NFS errors. > The naming scheme I chose to use was to write out the history data using > the name $HISTFILE.$$ since this naming idiom is already used for a > temporary file name when acquiring the $HISTFILE.LOCK lock file I wasn't aware of that latter; it should be changed. Using the PID as a disambiguator is also not safe when NFS is involved (two shells with the same PID on different hosts may be accessing the histfile in the same NFS-mounted home directory at the same time, unlikely as that seems). At the very least you should be open()ing with O_EXCL, and be prepared to recover if that fails (although O_EXCL is not reliable over NFS). > If folks think that $HISTFILE.new is a better choice, it would be easy > to change. No, that'd definitely be worse (even more likely to have conflict when multiple shells are rewriting the history), not better.