Zsh Mailing List Archive
Messages sorted by:
Reverse Date,
Date,
Thread,
Author
Re: [PATCH] history locking with fcntl
- X-seq: zsh-workers 24857
- From: Vincent Lefevre <vincent@xxxxxxxxxx>
- To: zsh-workers@xxxxxxxxxx
- Subject: Re: [PATCH] history locking with fcntl
- Date: Mon, 21 Apr 2008 15:19:37 +0200
- In-reply-to: <20080419023155.GB23964@xxxxxxxxx>
- Mail-followup-to: zsh-workers@xxxxxxxxxx
- Mailing-list: contact zsh-workers-help@xxxxxxxxxx; run by ezmlm
- References: <20080415153120.GE1223@xxxxxxxxxxxxxxxxxxx> <20080417162307.GB22594@xxxxxxxxx> <20080418005959.GB1067@xxxxxxxxxxxxxxxxxxx> <20080419023155.GB23964@xxxxxxxxx>
On 2008-04-18 19:31:55 -0700, Wayne Davison wrote:
> > I'll try it.
>
> Much appreciated.
I've done a few tests and don't get history corruption.
But my patch avoided a possible problem in rename() when there is a
tmpfile. With your patch, one still has:
if (fclose(out) < 0 && ret >= 0)
ret = -1;
if (ret >= 0) {
if (tmpfile) {
if (rename(tmpfile, unmeta(fn)) < 0)
zerr("can't rename %s.new to $HISTFILE", fn);
free(tmpfile);
tmpfile = NULL;
}
Note that since out has been closed, tmpfile is no longer locked.
The target file isn't locked either.
Now, I don't think that rename() can be cached. So, I'd say that there
should be no problems under "normal" conditions.
--
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 / Arenaire project (LIP, ENS-Lyon)
Messages sorted by:
Reverse Date,
Date,
Thread,
Author