75/d13962267045bb8db8c38167bc61a0a784025b

   1 Return-Path: <cworth@cworth.org>\r
   2 X-Original-To: notmuch@notmuchmail.org\r
   3 Delivered-To: notmuch@notmuchmail.org\r
   4 Received: from localhost (localhost [127.0.0.1])\r
   5         by olra.theworths.org (Postfix) with ESMTP id 6B3FB431FBC\r
   6         for <notmuch@notmuchmail.org>; Sat, 16 Jan 2010 18:33:22 -0800 (PST)\r
   7 X-Virus-Scanned: Debian amavisd-new at olra.theworths.org\r
   8 X-Spam-Flag: NO\r
   9 X-Spam-Score: -1.934\r
  10 X-Spam-Level: \r
  11 X-Spam-Status: No, score=-1.934 tagged_above=-999 required=5\r
  12         tests=[ALL_TRUSTED=-1.8, AWL=0.051, BAYES_40=-0.185] autolearn=ham\r
  13 Received: from olra.theworths.org ([127.0.0.1])\r
  14         by localhost (olra.theworths.org [127.0.0.1]) (amavisd-new, port 10024)\r
  15         with ESMTP id TSZ3YZvb8DRE; Sat, 16 Jan 2010 18:33:21 -0800 (PST)\r
  16 Received: from yoom.home.cworth.org (localhost [127.0.0.1])\r
  17         by olra.theworths.org (Postfix) with ESMTP id 0D47D431FAE;\r
  18         Sat, 16 Jan 2010 18:33:21 -0800 (PST)\r
  19 Received: by yoom.home.cworth.org (Postfix, from userid 1000)\r
  20         id A9A01254090; Sat, 16 Jan 2010 18:33:17 -0800 (PST)\r
  21 From: Carl Worth <cworth@cworth.org>\r
  22 To: Jameson Rollins <jrollins@finestructure.net>\r
  23 In-Reply-To: <20100116233840.GA31869@finestructure.net>\r
  24 References: <20100114084713.GA22273@harikalardiyari>\r
  25         <87eilse1hg.fsf@yoom.home.cworth.org>\r
  26         <20100115001600.GD25209@lapse.rw.madduck.net>\r
  27         <87vdf3cd1y.fsf@yoom.home.cworth.org>\r
  28         <20100115210934.GA12515@harikalardiyari>\r
  29         <87r5prc64e.fsf@yoom.home.cworth.org>\r
  30         <20100116201803.GA19570@finestructure.net>\r
  31         <87bpgtd71q.fsf@yoom.home.cworth.org>\r
  32         <20100116233840.GA31869@finestructure.net>\r
  33 Date: Sat, 16 Jan 2010 18:33:17 -0800\r
  34 Message-ID: <87pr59ihoy.fsf@yoom.home.cworth.org>\r
  35 MIME-Version: 1.0\r
  36 Content-Type: multipart/signed; boundary="=-=-=";\r
  37         micalg=pgp-sha1; protocol="application/pgp-signature"\r
  38 Cc: martin f krafft <madduck@madduck.net>, notmuch@notmuchmail.org\r
  39 Subject: Re: [notmuch] inbox/unread tags for new messages [was: Re: Thoughts\r
  40  on notmuch and Lua]\r
  41 X-BeenThere: notmuch@notmuchmail.org\r
  42 X-Mailman-Version: 2.1.13\r
  43 Precedence: list\r
  44 List-Id: "Use and development of the notmuch mail system."\r
  45         <notmuch.notmuchmail.org>\r
  46 List-Unsubscribe: <http://notmuchmail.org/mailman/options/notmuch>,\r
  47         <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>\r
  48 List-Archive: <http://notmuchmail.org/pipermail/notmuch>\r
  49 List-Post: <mailto:notmuch@notmuchmail.org>\r
  50 List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>\r
  51 List-Subscribe: <http://notmuchmail.org/mailman/listinfo/notmuch>,\r
  52         <mailto:notmuch-request@notmuchmail.org?subject=subscribe>\r
  53 X-List-Received-Date: Sun, 17 Jan 2010 02:33:22 -0000\r
  54 \r
  55 --=-=-=\r
  56 Content-Transfer-Encoding: quoted-printable\r
  57 \r
  58 On Sat, 16 Jan 2010 18:38:40 -0500, Jameson Rollins <jrollins@finestructure=\r
  59 .net> wrote:\r
  60 > Is it really a scheme change that would require delicate handling?\r
  61 \r
  62 Yes.\r
  63 \r
  64 > I would think that the change would be fairly straightforward:\r
  65 >=20\r
  66 > - if notmuch sees that a message in the maildir has moved from new to\r
  67 >   cur and/or the S flag has been added then any 'unread' flags should\r
  68 >   be removed from the message.\r
  69 >=20\r
  70 > - if a 'unread' tag is removed from a message, then the message S flag\r
  71 >   should be added.\r
  72 \r
  73 I have thousands of messages that I have read with sup and notmuch. The\r
  74 filenames have never changed since the mail was originally delivered by\r
  75 maildrop. So these messages are all in "new" directories, do not have\r
  76 the 'S' flag in the filename, and do not have an "unread" tag.\r
  77 \r
  78 So the database and the filesystem are currently inconsistent and\r
  79 neither of the above state changes will trigger for any of these\r
  80 messages.\r
  81 \r
  82 Things "work" fine for me now because I'm treating the database state as\r
  83 authoritative and ignoring the names of the files. Your proposal is to\r
  84 treat the filenames as authoritative, so will require an additional\r
  85 step, (to copy the current state from the database to the file names),\r
  86 besides what you've outlineed above.\r
  87 \r
  88 =2DCarl\r
  89 \r
  90 --=-=-=\r
  91 Content-Type: application/pgp-signature\r
  92 \r
  93 -----BEGIN PGP SIGNATURE-----\r
  94 Version: GnuPG v1.4.10 (GNU/Linux)\r
  95 \r
  96 iD8DBQFLUnbt6JDdNq8qSWgRAmEkAJ9FM0nP5yMbWBAepynpeDhMq36c4gCgg8MO\r
  97 3peYnW22zwDjlm4LFBGoFEE=\r
  98 =EVHZ\r
  99 -----END PGP SIGNATURE-----\r
 100 --=-=-=--\r