From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: zsh-users-return-23675-ml=inbox.vuxu.org@zsh.org X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-1.1 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,MAILING_LIST_MULTI,RCVD_IN_DNSWL_NONE autolearn=ham autolearn_force=no version=3.4.2 Received: from primenet.com.au (ns1.primenet.com.au [203.24.36.2]) by inbox.vuxu.org (OpenSMTPD) with ESMTP id 020274cd for ; Sun, 23 Sep 2018 15:45:34 +0000 (UTC) Received: (qmail 11073 invoked by alias); 23 Sep 2018 15:45:22 -0000 Mailing-List: contact zsh-users-help@zsh.org; run by ezmlm Precedence: bulk X-No-Archive: yes List-Id: Zsh Users List List-Post: List-Help: List-Unsubscribe: X-Seq: 23675 Received: (qmail 25168 invoked by uid 1010); 23 Sep 2018 15:45:22 -0000 X-Qmail-Scanner-Diagnostics: from out1-smtp.messagingengine.com by f.primenet.com.au (envelope-from , uid 7791) with qmail-scanner-2.11 (clamdscan: 0.99.2/21882. spamassassin: 3.4.1. Clear:RC:0(66.111.4.25):SA:0(-2.6/5.0):. Processed in 1.228571 secs); 23 Sep 2018 15:45:22 -0000 X-Envelope-From: d.s@daniel.shahaf.name X-Qmail-Scanner-Mime-Attachments: | X-Qmail-Scanner-Zip-Files: | DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= daniel.shahaf.name; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=ikO+p4 rNqBCdhEUiwxa+p1y+02+g1YQiUJLs1XzDnmk=; b=GTQBcxxVbSUNvzZ36ee6Nt Mo/gNIwklvy7P79Uaq8LWx3mnZQr2pzlZtElv5YKpmzRScSl6+3K9De+mOHtQzTL Ts4ZiHCTN6PnUopUZlFSi31+ifeog/zH1lN6lVe57sBjx3yjiAszeF87iqfqpOXL 1d5qFqqt8KiRhpfbQxHZMP5vx6ol6XMmHAa/oaOwUJqXpLX47JpiTluAHGfJzZjt lz1kxTdEDvAXtYuXpRPOuhaVCKs9/2e1DwU4bggmtS6VqARyC+wJAnBFr+8kpwQI S8lgoJ7W/gsAY7LAZonU/cm+uPWDoo1R1VUIhb8SJQKzrqJO9t2vPGV4cfVv6oZg == DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=ikO+p4 rNqBCdhEUiwxa+p1y+02+g1YQiUJLs1XzDnmk=; b=ZNIgsVynDFYaHZUHsLSjCr mSMutMy6UwwTNy7k+xXXCMrKppUHzXLRk06Wry8cuU/O2hYGOk02NFcR9TikFNeQ ZP4qX21TBBUoivpMXeVc9BRBjzVwv8uGrodyVJbj0X8ulF1paaEGeg8lIpSjQ/8G CCnUBCrjRf6ltJys67rgcQXEWhgKiLJ3GhE62gOVXZFyCN6vZrN7vYVkH9UWhhl4 wq3MiERZrXZTUnuSUeDqYMMmCJ/5nD1hQACPJor76GRms+47QUuMgiqZNsuN+eYN s3bLB2adPcsYAeGWr+/LzU0zkJ7ZQQCFcJSzEi9b9YWO6dg0nh+HH/VKyppoigWw == X-ME-Proxy: X-ME-Sender: Message-Id: <1537717517.130522.1517748104.07A63DB4@webmail.messagingengine.com> From: Daniel Shahaf To: lilydjwg Cc: zsh-users@zsh.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" X-Mailer: MessagingEngine.com Webmail Interface - ajax-e556cd15 Date: Sun, 23 Sep 2018 15:45:17 +0000 Subject: Re: No fsync on history file? I lost my history In-Reply-To: <20180923152546.GA6201@lilyforest.localdomain> References: <20180923085246.GA19251@lilyforest.localdomain> <1537709747.103981.1517680056.72C7A43E@webmail.messagingengine.com> <20180923142255.GA4931@lilyforest.localdomain> <1537714011.118073.1517716184.0B2E8824@webmail.messagingengine.com> <20180923152546.GA6201@lilyforest.localdomain> lilydjwg wrote on Sun, 23 Sep 2018 23:25 +0800: > On Sun, Sep 23, 2018 at 02:46:51PM +0000, Daniel Shahaf wrote: > > fsync() is in POSIX. I assume we can just call it, but if somebody complains > > we'll need to use an HAVE_FSYNC guard. > > I don't know how to add a HAVE_FSYNC macro to the build system, sorry. > I doubt that's needed. I had a quick look and found that libapr's apr_file_sync() call calls fsync() without a guard, implying that fsync() exists on all platforms libapr is used on. If we do need it, we'll add 'fsync' to the AC_CHECK_FUNCS call, regenerate configure (using Util/preconfig), and use #ifdef HAVE_FSYNC. > > > +++ b/Src/hist.c > > > @@ -2933,6 +2933,9 @@ savehistfile(char *fn, int err, int writeflags) > > > lasthist.text = ztrdup(start); > > > } > > > } > > > + fflush(out); /* need to flush before fsync */ > > > > Isn't the fflush() on line 2927 sufficient? (Even if it isn't, I would have > > expected a ret>=0 guard around this call.) > > It should call write(2) to write out the buffered data. Then the kernel > can fsync the data to disk. A guard has been added. > Yes, I understand that fflush(3) must be called in order to flush data from libc's buffers into kernel buffers, which fsync(2) will later flush to disk. My question was whether the fflush() call being added was redundant because of the existing call on line 2927. It would be odd to have two fflush() calls in a row without fwrite() between them; and to have only one of them update lasthist. Maybe it's all correct and it's just my lack of familiarity of hist.c that's showing. > > > + if (fsync(fileno(out)) < 0 && ret >= 0) > > > + ret = -1; > > > > fileno() can return -1. > > It shouldn't matter, fsync will return EBADF for -1. Other parts of the > code don't check for this either, and I can't think a case when fileno > would fail after so many successful I/O operations on it (corrupted memory?) > Fair enough. > > Shouldn't the ret>=0 check happen before the calls to fileno() and fsync()? > > Yes, I've changed that. Thanks. Daniel