Re: New message preservation

[John Goerzen <jgoerzen@xxxxxxxxxxxx>]

On Mon, Nov 04, 2002 at 01:25:34PM -0800, Jared Rhine wrote:
> Any insight on "fixing" the management of UNSEEN flags, as outlined
> below?  Are "new message" flags working fine for everyone else?

As far as I know, yes.

> I'm a brand new offlineimap user, running Debian 3.99.1 against a
> remote Courier-IMAP.

FYI, Courier IMAP is my testbed server as well.

> I've basically lost all management of "new" messages (IMAP Unseen
> status, I think).  Mail is delivered to my remote server fine; if I
> don't pull the message, then new messages are marked unseen, and when
> I point my mail user agent at the server and fetch new messages, they
> have a "new" mark, and the mail reader jumps to the new messages..

What mail reader are you using?  And what version?  Some versions of mutt
have a bug in this regard.

> I haven't traced the exact sequence yet.  Perhaps when offlineimap
> pulls the new messages, they are pulled with the unseen flag.  But
> then my remote server marked them as seen, so the _next_ sync, they
> get marked seen locally.

It should not do that; OfflineIMAP uses the IMAP "PEEK" command so that the
flags are not altered simply be the download of the message.

> I could bang my head on this a little bit, but I'd rather get guidance
> from the experts here.  Has anyone else experienced this issue?  Is it

I've seen things like this in older versions of mutt with buggy Maildir
code.  The newer versions handle it fine.  I haven't seen problems with any
other programs other than KMail (which has much larger problems).

> considered a problem?  When exactly are my local files been marked as
> seen?  Is offlineimap working the best that it can?  Are there any
> technically-incorrect-but-possibly-useful hacks that could be added to
> keep that seen bit long enough for it to make it to my MUA?
> 
> Thanks for any help.  I'd _really_ like to use offlineimap, but I'm
> feeling a productivity hit with the loss of my "new messages"
> functionality.
> 
> -- end --
> 
>