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 651826DE0C5F for ; Mon, 13 Jan 2020 14:33:11 -0800 (PST) Authentication-Results: arlo.cworth.org; dkim=pass (2048-bit key; unprotected) header.d=orangeseeds.org header.i=@orangeseeds.org header.b="ZAX7mqBn"; dkim-atps=neutral X-Virus-Scanned: Debian amavisd-new at cworth.org X-Spam-Flag: NO X-Spam-Score: -0.126 X-Spam-Level: X-Spam-Status: No, score=-0.126 tagged_above=-999 required=5 tests=[AWL=0.075, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] 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 6Rvt8q1F4x4Z for ; Mon, 13 Jan 2020 14:33:10 -0800 (PST) Received: from marcos.anarc.at (marcos.anarc.at [206.248.172.91]) by arlo.cworth.org (Postfix) with ESMTPS id A055B6DE0C1E for ; Mon, 13 Jan 2020 14:33:09 -0800 (PST) Received: by marcos.anarc.at (Postfix, from userid 1000) id 2386F10E07B; Mon, 13 Jan 2020 17:33:07 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=orangeseeds.org; s=marcos; t=1578954787; bh=+jE5/V+/ntsHYK8Rty5ZHlqrl4TERdgLR6UPvEE5XvQ=; h=From:To:Subject:In-Reply-To:References:Date:From; b=ZAX7mqBngGP16QesxJyzWSRWBBe2mNNeWj93stg/c0CWmJevNt2O2Go00OUt8uz2E FHyEwf1zFm0pmhcF/5xlJpDRr8zGxtNNAGixNecWalh0XsiBGKdlSvLxJDMCTDFQfX t3h4cSqRqj3KOvHmpIG0C9JedRmr8Wzy8fEh8ggDjnCJIkGkrUxB2r5FFAxrKQIWpf pLItNaYWnKLuRDMNC/mHZLYvPAs0isLuFgbUOrlY43tSpEtOd/FPsELLBT16b9gqf8 4kVv7FOvPxaA21GbdYrEMDvrYW1nTzHLtTbLvJ67mrAMVBc5yzGqZVxmRobxKJTleY r+lS8lcGPPDzA== Received: by curie.anarc.at (Postfix, from userid 1000) id 521A1120FFE; Mon, 13 Jan 2020 17:33:06 -0500 (EST) From: =?utf-8?Q?Antoine_Beaupr=C3=A9?= To: Daniel Kahn Gillmor , Notmuch Mail Subject: Re: proposing "notmuch purge" In-Reply-To: <87wo9vhtyh.fsf@fifthhorseman.net> References: <87wo9vhtyh.fsf@fifthhorseman.net> Date: Mon, 13 Jan 2020 17:33:06 -0500 Message-ID: <87lfqbx9zx.fsf@curie.anarc.at> MIME-Version: 1.0 Content-Type: text/plain X-BeenThere: notmuch@notmuchmail.org X-Mailman-Version: 2.1.29 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, 13 Jan 2020 22:33:11 -0000 On 2020-01-13 17:28:38, Daniel Kahn Gillmor wrote: > This e-mail proposes a new notmuch subcommand "purge", which actually > removes explicitly deleted messages from the mailstore. > > Notmuch currently never deletes mail, but notmuch-emacs makes it easy to > tag mail with "deleted" (via the "d") key, and "notmuch setup" > automatically adds "deleted" to the search.exclude_tags setting. > > Users typically do actually want to delete messages, and they want them > gone from their filesystem and from the index. I certainly do! :) > while everyone who has used notmuch for a while probably has a clever > way of doing this, those techniques are all probably slightly different > (and possibly buggy), and the cognitive burden of figuring out how to do > this sensibly for new users seems like something we should avoid. Agreed. > So i'm proposing "notmuch purge", which could be something as simple as > the equivalent of: > > notmuch search --output=files --format=text0 tag:deleted | \ > xargs --null --no-run-if-empty rm && \ > notmuch new --no-hooks > > (credit for the pipeline above goes to anarcat, in Cc; i added the > "notmuch new --no-hooks" part, because i would want the items gone from > the db as well) I don't quite understand that last bit. I deliberately do *not* run notmuch-new in my notmuch-purge script: https://gitlab.com/anarcat/scripts/blob/master/notmuch-purge ... because it's setup as a pre-new hook, so it runs right before new. So it doesn't need to call new. > If i was to implement this, i'd probably implement it directly in C, not > as a shell script, because this lets us drop messages from the db as we > unlink() the files. I also agree it might be faster than forking like crazy and rescanning the entire DB. But maybe we can just start with a shell wrapper for now. That's how many git subcommands start, by the way, and it might just be "good enough" for most people. > Inevitably, someone will come up with some more clever > options/generalizations (i can already think of at least one), but if we > have a particular implementation to hang these proposals on, it should > help us to build something sensibly robust with a wider consensus, and > new users can pick up and use that functionality easily/safely/with > confidence. > > I note that this is a divergence from the historical expectation of > having all "notmuch" subcommands not directly tamper with the > mailstore. I think given the context that divergence is OK. Well, we're already tampering with the mailstore: we're changing flags! :) > Any objections to this approach? Not from me, I've been advocating for data destruction for years now. Happy to get one more on my crew! ;) A. -- People arbitrarily, or as a matter of taste, assigning numerical values to non-numerical things. And then they pretend that they haven't just made the numbers up, which they have. Economics is like astrology in that sense, except that economics serves to justify the current power structure, and so it has a lot of fervent believers among the powerful. - Kim Stanley Robinson, Red Mars