Re: History corruption (over NFS)

[Vincent Lefevre <vincent@vinc17.org>]

On 2005-02-10 18:41:11 +0000, Bart Schaefer wrote:
> One thing to check is whether the file on the NFS server actually does
> contain those nul bytes, or if it's only the NFS client that sees them.
> I vaguely recall that you may need to explicitly specify "noac" in the
> NFS mount options, but it's been quite some time since I encountered
> this particular problem.

The "noac" didn't change anything (except making command execution
slower).

Here's what my corrupted .zhistory file looked like:

[...]
: 1108388462:0;ssh priam
^@^@^@^@^@^@^@^@[...]^@^@: 1108388476:0;t3-exec ulysse 0 -c=3 -l=3 [...]
: 1108390243:0;lt results.*
: 1108390256:0;head old-xtp/results.ctp.-3.54.1
: 1108390282:0;t3-secstep -f=ctp -e=-3 -m=54 -i=40 -n=44 --imax=7935
: 1108390290:0;screen -h 6000 -t server 1 zsh -c "./t3-server -v
+results.ctp.-3.54 2> server.out"
: 1108390309:0;ssh priam
[...]

If I've understood correctly, the first "ssh priam" started a zsh that
truncated the history file (since its size was above the limit). Note
that I quit this shell immediately. Then the current zsh instances
went on writing to the history file without noticing that it had been
truncated, hence the null bytes. The corrupt history was detected when
I started the second "ssh priam".

-- 
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 / SPACES project at LORIA