From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from localhost (localhost [127.0.0.1]) by arlo.cworth.org (Postfix) with ESMTP id A0D516DE0297 for ; Sat, 12 Nov 2016 07:39:42 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at cworth.org X-Spam-Flag: NO X-Spam-Score: -0.006 X-Spam-Level: X-Spam-Status: No, score=-0.006 tagged_above=-999 required=5 tests=[AWL=0.005, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=disabled Received: from arlo.cworth.org ([127.0.0.1]) by localhost (arlo.cworth.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wv8F7ydOYIFI for ; Sat, 12 Nov 2016 07:39:40 -0800 (PST) Received: from fethera.tethera.net (fethera.tethera.net [198.245.60.197]) by arlo.cworth.org (Postfix) with ESMTPS id A4F0F6DE00AC for ; Sat, 12 Nov 2016 07:39:40 -0800 (PST) Received: from remotemail by fethera.tethera.net with local (Exim 4.84_2) (envelope-from ) id 1c5aOi-0007Nl-Am; Sat, 12 Nov 2016 10:39:16 -0500 Received: (nullmailer pid 2255 invoked by uid 1000); Sat, 12 Nov 2016 15:39:34 -0000 From: David Bremner To: Paul Wise , Jani Nikula , notmuch@notmuchmail.org Subject: Re: [PATCH] cli: consider files vanishing during notmuch new non-fatal In-Reply-To: <1478352176.17295.5.camel@debian.org> References: <1478312104.1979.8.camel@debian.org> <1478350621-17137-1-git-send-email-jani@nikula.org> <1478352176.17295.5.camel@debian.org> Date: Sat, 12 Nov 2016 11:39:34 -0400 Message-ID: <87k2c8u2q1.fsf@tethera.net> MIME-Version: 1.0 Content-Type: text/plain X-BeenThere: notmuch@notmuchmail.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Use and development of the notmuch mail system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Nov 2016 15:39:42 -0000 Paul Wise writes: > On Sat, 2016-11-05 at 14:57 +0200, Jani Nikula wrote: > >> Add a new exit code for when files vanished, so the caller has a >> chance to detect the race and re-run notmuch new to recover. > > I don't think this is the right approach for two reasons: > > The exit code you have chosen is still a failure so I will still get > notified for a minor issue. I use chronic to detect fail scenarios. > > This is a pretty normal scenario when you have a mail program open and > are auto-running `notmuch new` on a scheduled basis or when new mail > arrives. notmuch should just ignore the error and continue as normal. > OK, but the patch proposed works both for people who want to be notified of this problem, and those that don't (with appropriate shell wrapping checking the return code). That seems better than hiding it for everyone. And certainly an improvement on the status quo. A possible future enhancement would be a flag like notmuch insert has to control the treatment of these errors. d