Zsh Mailing List Archive
Messages sorted by:
Reverse Date,
Date,
Thread,
Author
Re: History corruption (over NFS)
- X-seq: zsh-users 8499
- From: Vincent Lefevre <vincent@xxxxxxxxxx>
- To: zsh-users@xxxxxxxxxx
- Subject: Re: History corruption (over NFS)
- Date: Tue, 15 Feb 2005 10:58:41 +0100
- In-reply-to: <20050214185705.GC6444@xxxxxxxxx>
- Mail-followup-to: zsh-users@xxxxxxxxxx
- Mailing-list: contact zsh-users-help@xxxxxxxxxx; run by ezmlm
- References: <20050210165417.GG30487@xxxxxxxxxxxxx> <1050210184111.ZM22490@xxxxxxxxxxxxxxxxxxxxxxx> <20050214155630.GB6395@xxxxxxxxxxxxx> <20050214185705.GC6444@xxxxxxxxx>
On 2005-02-14 10:57:05 -0800, Wayne Davison wrote:
> A little while ago I wrote a patch that caused zsh to change its
> rewriting strategy to use a HISTORY_FILE.new file and then rename it
> into place. The purpose of this patch is to avoid losing any history
> if zsh gets interrupted during the writing of the new history file.
> However, it should also be a friendlier update strategy for NFS dirs
> because the inode of the file changes.
Will the other NFS clients necessarily notice the inode change?
Anyway it seems that this solution would work. I did a test with
Emacs, which changes the inode when modifying a file, simulating
what zsh does by removing some .zhistory lines at the beginning,
and there was no problem with NFS.
> The downside is that it can undo some user's use of symlinks,
> hardlinks, or special group permissions on their history file
> (because it is replacing the history file instead of rewriting it
> in-place). Perhaps this algorithm should be made optional?
Making it optional would be a good idea, much better than requiring
some mount options (which can slow down other applications...).
--
Vincent Lefèvre <vincent@xxxxxxxxxx> - Web: <http://www.vinc17.org/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/>
Work: CR INRIA - computer arithmetic / SPACES project at LORIA
Messages sorted by:
Reverse Date,
Date,
Thread,
Author