From: Carl Worth <cworth@cworth.org>
To: Jameson Rollins <jrollins@finestructure.net>
In-Reply-To: <20100116233840.GA31869@finestructure.net>
References: <20100114084713.GA22273@harikalardiyari>
	<87eilse1hg.fsf@yoom.home.cworth.org>
	<20100115001600.GD25209@lapse.rw.madduck.net>
	<87vdf3cd1y.fsf@yoom.home.cworth.org>
	<20100115210934.GA12515@harikalardiyari>
	<87r5prc64e.fsf@yoom.home.cworth.org>
	<20100116201803.GA19570@finestructure.net>
	<87bpgtd71q.fsf@yoom.home.cworth.org>
	<20100116233840.GA31869@finestructure.net>
Date: Sat, 16 Jan 2010 18:33:17 -0800
Message-ID: <87pr59ihoy.fsf@yoom.home.cworth.org>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-=";
	micalg=pgp-sha1; protocol="application/pgp-signature"
Cc: martin f krafft <madduck@madduck.net>, notmuch@notmuchmail.org
Subject: Re: [notmuch] inbox/unread tags for new messages [was: Re: Thoughts
 on notmuch and Lua]
Precedence: list

--=-=-=
Content-Transfer-Encoding: quoted-printable

On Sat, 16 Jan 2010 18:38:40 -0500, Jameson Rollins <jrollins@finestructure=
.net> wrote:
> Is it really a scheme change that would require delicate handling?

Yes.

> I would think that the change would be fairly straightforward:
>=20
> - if notmuch sees that a message in the maildir has moved from new to
>   cur and/or the S flag has been added then any 'unread' flags should
>   be removed from the message.
>=20
> - if a 'unread' tag is removed from a message, then the message S flag
>   should be added.

I have thousands of messages that I have read with sup and notmuch. The
filenames have never changed since the mail was originally delivered by
maildrop. So these messages are all in "new" directories, do not have
the 'S' flag in the filename, and do not have an "unread" tag.

So the database and the filesystem are currently inconsistent and
neither of the above state changes will trigger for any of these
messages.

Things "work" fine for me now because I'm treating the database state as
authoritative and ignoring the names of the files. Your proposal is to
treat the filenames as authoritative, so will require an additional
step, (to copy the current state from the database to the file names),
besides what you've outlineed above.

=2DCarl

--=-=-=
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)

iD8DBQFLUnbt6JDdNq8qSWgRAmEkAJ9FM0nP5yMbWBAepynpeDhMq36c4gCgg8MO
3peYnW22zwDjlm4LFBGoFEE=
=EVHZ
-----END PGP SIGNATURE-----
--=-=-=--