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 BFA496DE0226 for ; Mon, 30 Apr 2018 04:11:26 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at cworth.org X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[AWL=0.011, 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 ZwKrZ6QRKHgo for ; Mon, 30 Apr 2018 04:11:25 -0700 (PDT) Received: from fethera.tethera.net (fethera.tethera.net [198.245.60.197]) by arlo.cworth.org (Postfix) with ESMTPS id 4D17D6DE0225 for ; Mon, 30 Apr 2018 04:11:25 -0700 (PDT) Received: from remotemail by fethera.tethera.net with local (Exim 4.89) (envelope-from ) id 1fD6iI-0001Ck-Hb; Mon, 30 Apr 2018 07:11:22 -0400 Received: (nullmailer pid 4231 invoked by uid 1000); Mon, 30 Apr 2018 11:11:21 -0000 From: David Bremner To: Daniel Kahn Gillmor , notmuch@notmuchmail.org Subject: Re: [PATCH] CLI/restore: handle missing keys and values in config data. In-Reply-To: <87zi5p8dtw.fsf@fifthhorseman.net> References: <20180107213025.12848-1-david@tethera.net> <87zi5p8dtw.fsf@fifthhorseman.net> Date: Mon, 30 Apr 2018 08:11:21 -0300 Message-ID: <876049gd9i.fsf@tethera.net> MIME-Version: 1.0 Content-Type: text/plain X-BeenThere: notmuch@notmuchmail.org X-Mailman-Version: 2.1.26 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: Mon, 30 Apr 2018 11:11:26 -0000 Daniel Kahn Gillmor writes: > On Sun 2018-01-07 17:30:25 -0400, David Bremner wrote: >> Although such lines can't occur in notmuch dump output, they might be >> useful for clearing config, and anyway segfaulting is not the best >> error message. > > I don't think we want "notmuch restore" to actually clear any > configurations (it's always been additive thus far and changing that > seems dicey to me) It's not actually additive by default, that's why the '--accumulate' flag exists. It's true that the current patch ignores the accumulate flag, which could be fixed. The discussion after this gets side-tracked by the question of whether the (database) config values should allow empty strings. Since they currently don't, that's not an option for missing values. The proposed behaviour is potentially useful, but also potentially dangerous. I don't know that it is more dangerous than the existing default behaviour for tags, which is to delete them all, then add back those present in the dump file. Another option would be to just ignore such lines (and add some marker for empty string later, if/when that's supported). d