Zsh Mailing List Archive
Messages sorted by:
Reverse Date,
Date,
Thread,
Author
Re: [PATCH] Fix an issue where SIGINT leaves readhistfile in inconsistent state
- X-seq: zsh-workers 44068
- From: Peter Stephenson <p.stephenson@xxxxxxxxxxx>
- To: <zsh-workers@xxxxxxx>
- Subject: Re: [PATCH] Fix an issue where SIGINT leaves readhistfile in inconsistent state
- Date: Mon, 18 Feb 2019 10:11:39 +0000
- Cms-type: 201P
- Dkim-filter: OpenDKIM Filter v2.11.0 mailout2.w1.samsung.com 20190218101142euoutp027e1f8bdcacbd0bcb7dfaba15b74f16ab~EbZ81jJJU2544325443euoutp02s
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=samsung.com; s=mail20170921; t=1550484702; bh=7GuRWwS4ZNSqCgr25YtFmnjexDWP0zcNvAy3Ey/F+SY=; h=Subject:From:To:Date:In-Reply-To:References:From; b=O9R4FAvPL2iMas+a2BD6HV4wMnJPQGwVZEOcPAyc85nH0eHBQm0kehcv/LAzdedUu DR2CLsBaIJkT9ZYgRGtzwh9MIcxcpnE11g8slkXP+9Tv9uKr8aOQ6qxHu52wc9Komm Cu6mo4tfevsR1o6xES+12wShQ36o2lEDBhoqZpVk=
- In-reply-to: <CABvSBniueJdEVQ8D7EMKsoU2z2FD2M=ecUcuc4gEW4XbwYxajA@mail.gmail.com>
- List-help: <mailto:zsh-workers-help@zsh.org>
- List-id: Zsh Workers List <zsh-workers.zsh.org>
- List-post: <mailto:zsh-workers@zsh.org>
- List-unsubscribe: <mailto:zsh-workers-unsubscribe@zsh.org>
- Mailing-list: contact zsh-workers-help@xxxxxxx; run by ezmlm
- References: <CGME20190217044201epcas4p4ca093a5748a17d62dc9c5d418d0125c1@epcas4p4.samsung.com> <CABvSBniueJdEVQ8D7EMKsoU2z2FD2M=ecUcuc4gEW4XbwYxajA@mail.gmail.com>
On Sat, 2019-02-16 at 23:40 -0500, Yutian Li wrote:
> The issue I encountered is, when Zsh receives a SIGINT, it sets
> errflag |= ERRFLAG_INT so it will break out of the loop in
> readhistfile. But before we entered this loop we have already set
> lasthist.fsiz = sb.st_size and lasthist.mtim = sb.st_mtime so it looks
> like we have processed the history file up to the end already. And
> next time readhistfile is called, it will skip all processing and
> assume we have the entire history. This leaves Zsh in an inconsistent
> state, where history from different sessions could be lost.
>
> My proposed fix is to just add another flag to tell us if we've been
> interrupted from last time. If so, we don't skip processing.
That seems fine --- it looks like it ought to be safe. I've committed
it.
Thanks
pws
Messages sorted by:
Reverse Date,
Date,
Thread,
Author