Return-Path:
 <return-qkx7targe2yr8nmf7e3uvkr4hi@temporary-address.scs.stanford.edu>
X-Original-To: notmuch@notmuchmail.org
Delivered-To: notmuch@notmuchmail.org
Received: from localhost (localhost [127.0.0.1])
 by arlo.cworth.org (Postfix) with ESMTP id 58A766DE17FB
 for <notmuch@notmuchmail.org>; Mon, 31 Aug 2015 16:43:52 -0700 (PDT)
X-Virus-Scanned: Debian amavisd-new at cworth.org
X-Spam-Flag: NO
X-Spam-Score: -2.318
X-Spam-Level: 
X-Spam-Status: No, score=-2.318 tagged_above=-999 required=5 tests=[AWL=0.533,
  RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.55, 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 L9WnHlogszAN for <notmuch@notmuchmail.org>;
 Mon, 31 Aug 2015 16:43:50 -0700 (PDT)
Received: from market.scs.stanford.edu (market.scs.stanford.edu [171.66.3.10])
 by arlo.cworth.org (Postfix) with ESMTPS id F057C6DE1416
 for <notmuch@notmuchmail.org>; Mon, 31 Aug 2015 16:43:49 -0700 (PDT)
Received: from market.scs.stanford.edu (localhost.scs.stanford.edu
 [127.0.0.1]) by market.scs.stanford.edu (8.14.7/8.14.7) with ESMTP id
 t7VNhhA9010565; Mon, 31 Aug 2015 16:43:43 -0700 (PDT)
Received: (from dm@localhost)
 by market.scs.stanford.edu (8.14.7/8.14.7/Submit) id t7VNhhXk003003;
 Mon, 31 Aug 2015 16:43:43 -0700 (PDT)
X-Authentication-Warning: market.scs.stanford.edu: dm set sender to
 return-qkx7targe2yr8nmf7e3uvkr4hi@ta.scs.stanford.edu using -f
From: David Mazieres <dm-list-email-notmuch@scs.stanford.edu>
To: Amadeusz =?utf-8?B?xbtvxYJub3dza2k=?= <aidecoe@aidecoe.name>
Subject: Re: muchsync files renames
In-Reply-To: <87egijm7kw.fsf@freja.aidecoe.name>
References: <878u93ujdo.fsf@freja.aidecoe.name>
 <876146o920.fsf@ta.scs.stanford.edu> <871teu8kdd.fsf@freja.aidecoe.name>
 <87oahxojlv.fsf@ta.scs.stanford.edu> <87vbbwnbb4.fsf@freja.aidecoe.name>
 <87io7wr50y.fsf@ta.scs.stanford.edu> <87k2sbmzww.fsf@freja.aidecoe.name>
 <87oahnmkqf.fsf@ta.scs.stanford.edu> <87egijm7kw.fsf@freja.aidecoe.name>
Reply-To: David Mazieres expires 2015-11-29 PST
 <mazieres-sggp47c7j46624db3rharctcei@temporary-address.scs.stanford.edu>
Date: Mon, 31 Aug 2015 16:43:42 -0700
Message-ID: <878u8rvxap.fsf@ta.scs.stanford.edu>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Cc: notmuch@notmuchmail.org
X-BeenThere: notmuch@notmuchmail.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: "Use and development of the notmuch mail system."
 <notmuch.notmuchmail.org>
List-Unsubscribe: <http://notmuchmail.org/mailman/options/notmuch>,
 <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>
List-Archive: <http://notmuchmail.org/pipermail/notmuch/>
List-Post: <mailto:notmuch@notmuchmail.org>
List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>
List-Subscribe: <http://notmuchmail.org/mailman/listinfo/notmuch>,
 <mailto:notmuch-request@notmuchmail.org?subject=subscribe>
X-List-Received-Date: Mon, 31 Aug 2015 23:43:52 -0000

Amadeusz =C5=BBo=C5=82nowski <aidecoe@aidecoe.name> writes:

> Not necessarily. The recommended setup of notmuch for afew is that
> "notmuch new" tags messages with "new" tag only. Then afew processes all
> messages with "new" tag. So if it is a spam, then it gets "new" removed
> and "spam" added. A spam message at any time doesn't have "unread" tag
> assigned which should explain this behaviour.  So the problem is to be
> fixed on the afew side.

Let's just make sure I understand:  Your mail starts out like this:

    Path:  spam/new/nnn.MnnnPnnnQnRn.machine
    Tags:  new

Then you run afew, and afew runs

    notmuch tag -new +spam <message-ID>

You are saying that that even though maildir.synchronize_tags is true,
you end up with:

    Path:  spam/new/nnn.MnnnPnnnQnRn.machine
    Tags:  spam

That's a little surprising, because the next time you run "notmuch new,"
I would have expected it to add the unread flag based on the pathname.
But, I suppose it might make sense for notmuch to special-case that
flag.  In other words, if notmuch new finds a file called:

    spam/new/nnn.MnnnPnnnQnRn.machine:2,

Then it will add the unread tag to the Xapian database.  But maybe if it
finds a file in the new folder it doesn't add the unread flag.

But why does notmuch_message_tags_to_maildir_flag() then feel the need
to rename the file when muchsync calls it.  Muchsync should ideally
behave exactly the same as the notmuch tag command.  Specifically, when
muchsync receives a new file from the server, it does the following:

 1. create file in same directory as the server (presumably spam/new)

 2. Call the following functions on this file:
      notmuch_database_add_message()
      notmuch_message_freeze()
      notmuch_message_remove_all_tags()
      notmuch_message_add_tag() for each tag in new.tags
      if (synchronize_tags) notmuch_message_tags_to_maildir_flag()
      notmuch_message_thaw()

 3. get the current tags of the message from the server (presumably just
    spam)

 4. Call the following functions on the Message-ID:
      notmuch_message_freeze()
      notmuch_message_remove_all_tags()
      notmuch_message_add_tag() for each tag sent *by the server*
      if (synchronize_tags) notmuch_message_tags_to_maildir_flag()
      notmuch_message_thaw()

So what I'm wondering is how this is any different from what is already
happening on the server.  "notmuch new" should be doing what muchsync
does in step 2, and afew (via "notmuch tag") should be doing what
muchsync does in step 4.

Yet somehow you are saying that on the server the file stays in
spam/new/, while on the client muchsync's actions cause the file to move
to spam/cur/?  So that means there's still something I don't really
understand--possibly the series of notmuch library calls happening
server side (which I should then maybe emulate client side).

None of this is super serious, beyond a one-time extra cost, but I like
to understand things thoroughly, particularly when writing software that
manipulates critical data like mail...

It there any possibility that new.tags has a different setting on your
client and server machines?

Thanks,
David