Zsh Mailing List Archive
Messages sorted by:
Re: skip rewriting history if exiting due to signal
- X-seq: zsh-workers 20497
- From: Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>
- To: zsh-workers@xxxxxxxxxx
- Subject: Re: skip rewriting history if exiting due to signal
- Date: Sun, 17 Oct 2004 17:21:18 -0700 (PDT)
- In-reply-to: <20041017194842.GA26158@xxxxxxxxx>
- Mailing-list: contact zsh-workers-help@xxxxxxxxxx; run by ezmlm
- References: <20041001193658.GD26529@xxxxxxxxx> <20041017194842.GA26158@xxxxxxxxx>
- Reply-to: zsh-workers@xxxxxxxxxx
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
- 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.
Messages sorted by: