--- /dev/null
+Return-Path: <Sebastian@SSpaeth.de>\r
+X-Original-To: notmuch@notmuchmail.org\r
+Delivered-To: notmuch@notmuchmail.org\r
+Received: from localhost (localhost [127.0.0.1])\r
+ by olra.theworths.org (Postfix) with ESMTP id 9FEAC40BFDF\r
+ for <notmuch@notmuchmail.org>; Mon, 20 Sep 2010 08:09:39 -0700 (PDT)\r
+X-Virus-Scanned: Debian amavisd-new at olra.theworths.org\r
+X-Spam-Flag: NO\r
+X-Spam-Score: -2\r
+X-Spam-Level: \r
+X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,\r
+ DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=ham\r
+Received: from olra.theworths.org ([127.0.0.1])\r
+ by localhost (olra.theworths.org [127.0.0.1]) (amavisd-new, port 10024)\r
+ with ESMTP id rdddLwoZg9mv for <notmuch@notmuchmail.org>;\r
+ Mon, 20 Sep 2010 08:09:29 -0700 (PDT)\r
+Received: from homiemail-a22.g.dreamhost.com (caiajhbdcbbj.dreamhost.com\r
+ [208.97.132.119])\r
+ by olra.theworths.org (Postfix) with ESMTP id E296C40BD85\r
+ for <notmuch@notmuchmail.org>; Mon, 20 Sep 2010 08:09:28 -0700 (PDT)\r
+Received: from homiemail-a22.g.dreamhost.com (localhost [127.0.0.1])\r
+ by homiemail-a22.g.dreamhost.com (Postfix) with ESMTP id 029C41A808E;\r
+ Mon, 20 Sep 2010 08:09:29 -0700 (PDT)\r
+DomainKey-Signature: a=rsa-sha1; c=nofws; d=SSpaeth.de; h=from:to:cc:subject\r
+ :in-reply-to:references:date:message-id:mime-version:\r
+ content-type; q=dns; s=sspaeth.de; b=kk2OLT3QowLvGKsoGd91GnOFESx\r
+ LeuUyPna7qTgGxeKV7Z2PEof74Zec1Qd4IwUbTY8IHie4ovRTrvEf+9PwUy9+xCS\r
+ NbGpuiGvpXaW/BMMN0mGjq3yjct8H8UTP0rOBRoBjCYw1AMzQYEe2o7hIybpSFmg\r
+ CxgEGAv9y7rCJg/4=\r
+DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=SSpaeth.de; h=from:to:cc\r
+ :subject:in-reply-to:references:date:message-id:mime-version:\r
+ content-type; s=sspaeth.de; bh=0MDDKFHWHYKPb2mZTIWvlyeIdMM=; b=A\r
+ fr5RS8hJPYCzTT5Tuo2GjdN+ZmhRObN/Z2KJ2b6u9sANi6mu+5632euHFmcmab7U\r
+ wzi+uJy4EUZkZop+6I5vLrPw2irIVRvpOkhg4CdVZuMFjH09sptE4j43un+rM7qV\r
+ kW24Z0MaieJJiaN/HM46jvGYcqMqTD0pE/6KDeeRAo=\r
+Received: from spaetzbook.sspaeth.de (mtec-hg-docking-2-dhcp-016.ethz.ch\r
+ [82.130.121.16]) (Authenticated sender: fax@sspaeth.de)\r
+ by homiemail-a22.g.dreamhost.com (Postfix) with ESMTPA id 7203C1A808D; \r
+ Mon, 20 Sep 2010 08:09:27 -0700 (PDT)\r
+Received: by spaetzbook.sspaeth.de (sSMTP sendmail emulation);\r
+ Mon, 20 Sep 2010 17:09:25 +0200\r
+From: Sebastian Spaeth <Sebastian@SSpaeth.de>\r
+To: Rob Browning <rlb@defaultvalue.org>\r
+Subject: Re: notmuchsync: handling of the deleted tag\r
+In-Reply-To: <87bp7vewa5.fsf@raven.defaultvalue.org>\r
+References: <87bp7vewa5.fsf@raven.defaultvalue.org>\r
+User-Agent: Notmuch/0.3.1-43-g5d515b7 (http://notmuchmail.org) Emacs/23.1.50.1\r
+ (x86_64-pc-linux-gnu)\r
+Date: Mon, 20 Sep 2010 17:09:25 +0200\r
+Message-ID: <87mxrcsb8a.fsf@SSpaeth.de>\r
+MIME-Version: 1.0\r
+Content-Type: text/plain; charset=us-ascii\r
+Cc: Notmuch developer list <notmuch@notmuchmail.org>\r
+X-BeenThere: notmuch@notmuchmail.org\r
+X-Mailman-Version: 2.1.13\r
+Precedence: list\r
+List-Id: "Use and development of the notmuch mail system."\r
+ <notmuch.notmuchmail.org>\r
+List-Unsubscribe: <http://notmuchmail.org/mailman/options/notmuch>,\r
+ <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>\r
+List-Archive: <http://notmuchmail.org/pipermail/notmuch>\r
+List-Post: <mailto:notmuch@notmuchmail.org>\r
+List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>\r
+List-Subscribe: <http://notmuchmail.org/mailman/listinfo/notmuch>,\r
+ <mailto:notmuch-request@notmuchmail.org?subject=subscribe>\r
+X-List-Received-Date: Mon, 20 Sep 2010 15:09:39 -0000\r
+\r
+On 2010-09-18, Rob Browning wrote:\r
+> I've been trying notmuchsync, and it's quite helpful, but I just ran\r
+> across something that caused me a bit of concern. I noticed that some\r
+> messages were marked deleted that I'm fairly certain I didn't intend to\r
+> delete.\r
+> \r
+> My suspicion is that this is because I received two copies of the\r
+> message and I marked one of them for deletion (expiry) in Gnus, but not\r
+> the other one. Since notmuch doesn't normally distinguish between two\r
+> messages with the same id, I suspected that notmuchsync might not notice\r
+> either. Is that possible?\r
+\r
+Yes, that is certainly possible. notmuchsync checks if a file should be\r
+deleted ("pruning") like this:\r
+\r
+1)Run notmuchsync --revsync (or -r) and it will examine your mail\r
+files. If a mail is trashed (expired) according to maildir flags in its\r
+filename, it will add the tag "deleted" to the mail's id in the notmuch\r
+database. If you have multiple copies with the same message that tag is\r
+now associated with the mail id, not the actual file.\r
+\r
+2) Run notmuchsync --prune which runs the query: "tag:delete or\r
+tag:deleted or tag:maildir::trashed" by default. \r
+\r
+To which notmuch returns a list of messages and a corresponding filename\r
+for each id. If there are multiple messages with the same id, I think it\r
+will return the first filename that was associated with that mail id, so\r
+it is kind of random which file location gets returned. The returned\r
+file names are associated with the "deleted" tag - and thus - unlinked.\r
+\r
+I am unsure how to handle this in a better way. What should notmuchsync\r
+--prune do if it finds multiple mail files that are associated with a\r
+"deleted" tag? And what should --revsync do when it finds a mail file\r
+that is marked as expired. As long as notmuch only offers one data entry\r
+per mail id, there will remain some ambiguity as to how to handle these.\r
+\r
+\r
+If notmuch gave me at least all filenames that are associated with a\r
+mail id, I could introduce a command line option "--prune --safe" which would\r
+Sebastian\r
+\r
+P.S. CC'ing the notmuch list as this is potentially an issue that\r
+affects people.\r
projects / notmuch-archives.git / commitdiff