corrupt history file on NFS

corrupt history file on NFS

[Vincent Lefevre]

I regularly have a corrupt history file with zsh 4.3.2. The problem
appeared when one of the machine was upgraded to x86_64 + zsh 4.3.2
(previously it was under Debian/stable, therefore i386 + zsh 4.2.1).
I have the following options set:

courge:~> setopt | grep hist
extendedhistory
histignoredups
histignorespace
histnofunctions
histnostore
histreduceblanks
incappendhistory

-- 
Vincent Lefèvre <vincent@vinc17.org> - Web: <http://www.vinc17.org/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/>
Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon)

Re: corrupt history file on NFS

[Wayne Davison]

On Sun, Jan 14, 2007 at 09:25:54PM +0100, Vincent Lefevre wrote:
> I regularly have a corrupt history file with zsh 4.3.2.

Corrupt in what way?

..wayne..

Re: corrupt history file on NFS

[Vincent Lefevre]

On 2007-01-14 19:27:16 -0800, Wayne Davison wrote:
> On Sun, Jan 14, 2007 at 09:25:54PM +0100, Vincent Lefevre wrote:
> > I regularly have a corrupt history file with zsh 4.3.2.
> 
> Corrupt in what way?

I've done several tests, and here's more information:

* The problem occurs when I use two different machines (called courge
and doubleeagle), both x86_64.

* When a corruption occurs, there are null bytes in the history file.

* The corruption occurs almost systematically (or at least very often)
when I type a command on courge, then a command on doubleeagle. But it
*never* occurs if I read the history file with less before typing the
command. Note: the less command line isn't stored to the history file
because I either type a space first (I use histignorespace) or make
sure to recall the previous "less ..." command (I use histignoredups).

-- 
Vincent Lefèvre <vincent@vinc17.org> - Web: <http://www.vinc17.org/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/>
Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon)

Re: corrupt history file on NFS

[Bart Schaefer]

On Jan 16,  3:03am, Vincent Lefevre wrote:
}
} *never* occurs if I read the history file with less before typing the

This sounds like an NFS synchronization issue.  Reading the file forces
the first write to be flushed out of the NFS cache.

This suggests that we might be able to work around it by always having
zsh seek to one btye short of the file size, and then read that byte,
before it attempts to append anything to the file.  However, it's really
not zsh's fault:  NFS writes are not required to be atomic, and zsh does
not know the file isn't local.  So this would have to be controlled by
an option, or something, so as not to penalize cases that don't need
NFS "safety".

Re: corrupt history file on NFS

[Vincent Lefevre]

On 2007-01-15 19:00:43 -0800, Bart Schaefer wrote:
> This suggests that we might be able to work around it by always having
> zsh seek to one btye short of the file size, and then read that byte,
> before it attempts to append anything to the file.

If you have a patch, I can test it to make sure this solves the problem.

> However, it's really not zsh's fault: NFS writes are not required to
> be atomic, and zsh does not know the file isn't local. So this would
> have to be controlled by an option, or something, so as not to
> penalize cases that don't need NFS "safety".

An option would be OK for me, but would this really penalize cases
with local files in practice?

-- 
Vincent Lefèvre <vincent@vinc17.org> - Web: <http://www.vinc17.org/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/>
Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon)