all nnimap flags lost again

all nnimap flags lost again

[Dan Christensen]

Starting a new thread for this.  With current git version, I lost all
flags (except \Seen) in another IMAP group.  I had about 100 expirable
articles mixed in with various read, ticked and dormant articles, so I
had to go through and figure out which ones I had meant to get rid of.

Then, after setting the `E' mark on about a hundred articles, I exited
the group.  When I reentered, the marks were gone again!  So I set them
again, exited and reentered, and then they were there.  I decide to quit
gnus and emacs in case some data structure was corrupted.  When I
restarted, the marks were gone again.

Since this is repeatable, maybe we can debug it?  Here's my *imap log*
from one of the times that it happened:

20:59:56 68 SELECT "generic"
20:59:56 69 UID FETCH 29:2328 (UID RFC822.SIZE BODYSTRUCTURE BODY.PEEK[HEADER.FIELDS (Subject From Date Message-Id References In-Reply-To Xref X-Spam-Status To Cc Keywords Newsgroups Subject)])
21:00:26 70 UID STORE 2173:2181,2183:2224,2226:2279,2281:2315,2317:2327 +FLAGS.SILENT (gnus-expire)

A lot of the articles are set to expire.

21:00:29 71 SELECT "generic"
21:00:29 72 UID FETCH 29:2328 (UID RFC822.SIZE BODYSTRUCTURE BODY.PEEK[HEADER.FIELDS (Subject From Date Message-Id References In-Reply-To Xref X-Spam-Status To Cc Keywords Newsgroups Subject)])
21:00:35 73 SELECT "generic"
21:00:35 74 UID FETCH 29:2328 (UID RFC822.SIZE BODYSTRUCTURE BODY.PEEK[HEADER.FIELDS (Subject From Date Message-Id References In-Reply-To Xref X-Spam-Status To Cc Keywords Newsgroups Subject)])

I think I entered the group twice, and both times it was fine.

21:01:12 75 SELECT "generic"
21:01:12 76 UID FETCH 1:* FLAGS

That's probably me hitting `M-g'.

21:01:13 77 SELECT "generic"
21:01:13 78 UID FETCH 29:2328 (UID RFC822.SIZE BODYSTRUCTURE BODY.PEEK[HEADER.FIELDS (Subject From Date Message-Id References In-Reply-To Xref X-Spam-Status To Cc Keywords Newsgroups Subject)])

And then I entered the group and the flags were all gone.

Also, I don't know if it's related, but when I hit SPC on an nnimap
group right after starting Gnus, it only shows me the articles whose
numbers are within 100 of the most recent.  I was hoping that the trick
of just looking at the last 100 would be completely internal.

Dan

Re: all nnimap flags lost again

[Lars Magne Ingebrigtsen]

Dan Christensen <jdc@uwo.ca> writes:

> Then, after setting the `E' mark on about a hundred articles, I exited
> the group.  When I reentered, the marks were gone again!  So I set them
> again, exited and reentered, and then they were there.  I decide to quit
> gnus and emacs in case some data structure was corrupted.  When I
> restarted, the marks were gone again.

Cripes.

> Since this is repeatable, maybe we can debug it?  Here's my *imap log*
> from one of the times that it happened:
>
> 20:59:56 68 SELECT "generic"
> 20:59:56 69 UID FETCH 29:2328 (UID RFC822.SIZE BODYSTRUCTURE BODY.PEEK[HEADER.FIELDS (Subject From Date Message-Id References In-Reply-To Xref X-Spam-Status To Cc Keywords Newsgroups Subject)])
> 21:00:26 70 UID STORE 2173:2181,2183:2224,2226:2279,2281:2315,2317:2327 +FLAGS.SILENT (gnus-expire)
>
> A lot of the articles are set to expire.

It's setting the marks OK.  But I can't see from any of the excerpts
that it removes the marks from the servers?  There's no "-FLAGS.SILENT"
in your logs?  Then the flags are still on the IMAP server -- it's only
Gnus that's not discovering them correctly.

> I think I entered the group twice, and both times it was fine.
>
> 21:01:12 75 SELECT "generic"
> 21:01:12 76 UID FETCH 1:* FLAGS
>
> That's probably me hitting `M-g'.
>
> 21:01:13 77 SELECT "generic"
> 21:01:13 78 UID FETCH 29:2328 (UID RFC822.SIZE BODYSTRUCTURE BODY.PEEK[HEADER.FIELDS (Subject From Date Message-Id References In-Reply-To Xref X-Spam-Status To Cc Keywords Newsgroups Subject)])

So `M-g' doesn't even restore the marks now?

There must be a basic marks parsing problem now.  Can you send the
complete contents of the *nnimap ... * buffer after doing one `M-g' on
the group?

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: all nnimap flags lost again

[Dan Christensen]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> Dan Christensen <jdc@uwo.ca> writes:
>
> It's setting the marks OK.  But I can't see from any of the excerpts
> that it removes the marks from the servers?  There's no "-FLAGS.SILENT"
> in your logs?  Then the flags are still on the IMAP server -- it's only
> Gnus that's not discovering them correctly.

I think you are right.  Although I think that during my experiments,
they also sometimes change on the server, since my offlineimap run
shows that it is syncing changes to the remote server.  But other
times, no sync happens.

> So `M-g' doesn't even restore the marks now?

Nope.  In fact, that seems to be what triggers them getting lost.

> There must be a basic marks parsing problem now.  Can you send the
> complete contents of the *nnimap ... * buffer after doing one `M-g' on
> the group?

Can you increase the size of that buffer, as it often doesn't contain
the results from a single action?  I switched groups here to another
one "root" which shows the same problem, and just a bit at the beginning
is truncated.  So you see that the gnus-expire marks are there, but
aren't found by Gnus.

* FLAGS (%Answered %Flagged %Deleted %Seen %Draft gnus-expire gnus-dormant)
* OK [PERMANENTFLAGS (%Answered %Flagged %Deleted %Seen %Draft gnus-expire gnus-dormant %*)] Flags permitted.
* 113 EXISTS
* 0 RECENT
* OK [UIDVALIDITY 1256067223] UIDs valid
* OK [UIDNEXT 1799] Predicted next UID
183 OK [READ-WRITE] Select completed.
* 1 FETCH (UID 757 FLAGS (%Seen))
* 2 FETCH (UID 759 FLAGS (%Seen))
* 3 FETCH (UID 763 FLAGS (%Seen))
* 4 FETCH (UID 1671 FLAGS (%Seen gnus-expire))
* 5 FETCH (UID 1672 FLAGS (%Seen gnus-expire))
* 6 FETCH (UID 1673 FLAGS (%Seen gnus-expire))
* 7 FETCH (UID 1674 FLAGS (%Seen gnus-expire))
* 8 FETCH (UID 1675 FLAGS (%Seen gnus-expire))
* 9 FETCH (UID 1676 FLAGS (%Seen gnus-expire))
* 10 FETCH (UID 1677 FLAGS (%Seen gnus-expire))
* 11 FETCH (UID 1678 FLAGS (%Seen gnus-expire))
* 12 FETCH (UID 1697 FLAGS (%Seen gnus-expire))
* 13 FETCH (UID 1698 FLAGS (%Seen gnus-expire))
* 14 FETCH (UID 1699 FLAGS (%Seen gnus-expire))
* 15 FETCH (UID 1700 FLAGS (%Seen gnus-expire))
* 16 FETCH (UID 1701 FLAGS (%Seen gnus-expire))
* 17 FETCH (UID 1702 FLAGS (%Seen gnus-expire))
* 18 FETCH (UID 1703 FLAGS (%Seen gnus-expire))
* 19 FETCH (UID 1704 FLAGS (%Seen gnus-expire))
* 20 FETCH (UID 1705 FLAGS (%Seen gnus-expire))
* 21 FETCH (UID 1706 FLAGS (%Seen gnus-expire))
* 22 FETCH (UID 1707 FLAGS (%Seen gnus-expire))
* 23 FETCH (UID 1708 FLAGS (%Seen gnus-expire))
* 24 FETCH (UID 1709 FLAGS (%Seen gnus-expire))
* 25 FETCH (UID 1710 FLAGS (%Seen gnus-expire))
* 26 FETCH (UID 1711 FLAGS (%Seen gnus-expire))
* 27 FETCH (UID 1712 FLAGS (%Seen gnus-expire))
* 28 FETCH (UID 1713 FLAGS (%Seen gnus-expire))
* 29 FETCH (UID 1714 FLAGS (%Seen gnus-expire))
* 30 FETCH (UID 1715 FLAGS (%Seen gnus-expire))
* 31 FETCH (UID 1716 FLAGS (%Seen gnus-expire))
* 32 FETCH (UID 1717 FLAGS (%Seen gnus-expire))
* 33 FETCH (UID 1718 FLAGS (%Seen gnus-expire))
* 34 FETCH (UID 1719 FLAGS (%Seen gnus-expire))
* 35 FETCH (UID 1720 FLAGS (%Seen gnus-expire))
* 36 FETCH (UID 1721 FLAGS (%Seen gnus-expire))
* 37 FETCH (UID 1722 FLAGS (%Seen gnus-expire))
* 38 FETCH (UID 1723 FLAGS (%Seen gnus-expire))
* 39 FETCH (UID 1724 FLAGS (%Seen gnus-expire))
* 40 FETCH (UID 1725 FLAGS (%Seen gnus-expire))
* 41 FETCH (UID 1726 FLAGS (%Seen gnus-expire))
* 42 FETCH (UID 1727 FLAGS (%Seen gnus-expire))
* 43 FETCH (UID 1728 FLAGS (%Seen gnus-expire))
* 44 FETCH (UID 1729 FLAGS (%Seen gnus-expire))
* 45 FETCH (UID 1730 FLAGS (%Seen gnus-expire))
* 46 FETCH (UID 1731 FLAGS (%Seen gnus-expire))
* 47 FETCH (UID 1732 FLAGS (%Seen gnus-expire))
* 48 FETCH (UID 1733 FLAGS (%Seen gnus-expire))
* 49 FETCH (UID 1734 FLAGS (%Seen gnus-expire))
* 50 FETCH (UID 1735 FLAGS (%Seen gnus-expire))
* 51 FETCH (UID 1736 FLAGS (%Seen gnus-expire))
* 52 FETCH (UID 1737 FLAGS (%Seen gnus-expire))
* 53 FETCH (UID 1738 FLAGS (%Seen gnus-expire))
* 54 FETCH (UID 1739 FLAGS (%Seen gnus-expire))
* 55 FETCH (UID 1740 FLAGS (%Seen gnus-expire))
* 56 FETCH (UID 1741 FLAGS (%Seen gnus-expire))
* 57 FETCH (UID 1742 FLAGS (%Seen gnus-expire))
* 58 FETCH (UID 1743 FLAGS (%Seen gnus-expire))
* 59 FETCH (UID 1744 FLAGS (%Seen gnus-expire))
* 60 FETCH (UID 1745 FLAGS (%Seen gnus-expire))
* 61 FETCH (UID 1746 FLAGS (%Seen gnus-expire))
* 62 FETCH (UID 1747 FLAGS (%Seen gnus-expire))
* 63 FETCH (UID 1748 FLAGS (%Seen gnus-expire))
* 64 FETCH (UID 1749 FLAGS (%Seen gnus-expire))
* 65 FETCH (UID 1750 FLAGS (%Seen gnus-expire))
* 66 FETCH (UID 1751 FLAGS (%Seen gnus-expire))
* 67 FETCH (UID 1752 FLAGS (%Seen gnus-expire))
* 68 FETCH (UID 1753 FLAGS (%Seen gnus-expire))
* 69 FETCH (UID 1754 FLAGS (%Seen gnus-expire))
* 70 FETCH (UID 1755 FLAGS (%Seen gnus-expire))
* 71 FETCH (UID 1756 FLAGS (%Seen gnus-expire))
* 72 FETCH (UID 1757 FLAGS (%Seen gnus-expire))
* 73 FETCH (UID 1758 FLAGS (%Seen gnus-expire))
* 74 FETCH (UID 1759 FLAGS (%Seen gnus-expire))
* 75 FETCH (UID 1760 FLAGS (%Seen gnus-expire))
* 76 FETCH (UID 1761 FLAGS (%Seen gnus-expire))
* 77 FETCH (UID 1762 FLAGS (%Seen gnus-expire))
* 78 FETCH (UID 1763 FLAGS (%Seen gnus-expire))
* 79 FETCH (UID 1764 FLAGS (%Seen gnus-expire))
* 80 FETCH (UID 1765 FLAGS (%Seen gnus-expire))
* 81 FETCH (UID 1766 FLAGS (%Seen gnus-expire))
* 82 FETCH (UID 1767 FLAGS (%Seen gnus-expire))
* 83 FETCH (UID 1768 FLAGS (%Seen gnus-expire))
* 84 FETCH (UID 1769 FLAGS (%Seen gnus-expire))
* 85 FETCH (UID 1770 FLAGS (%Seen gnus-expire))
* 86 FETCH (UID 1771 FLAGS (%Seen gnus-expire))
* 87 FETCH (UID 1772 FLAGS (%Seen gnus-expire))
* 88 FETCH (UID 1773 FLAGS (%Seen gnus-expire))
* 89 FETCH (UID 1774 FLAGS (%Seen gnus-expire))
* 90 FETCH (UID 1775 FLAGS (%Seen gnus-expire))
* 91 FETCH (UID 1776 FLAGS (%Seen gnus-expire))
* 92 FETCH (UID 1777 FLAGS (%Seen gnus-expire))
* 93 FETCH (UID 1778 FLAGS (%Seen gnus-expire))
* 94 FETCH (UID 1779 FLAGS (%Seen gnus-expire))
* 95 FETCH (UID 1780 FLAGS (%Seen gnus-expire))
* 96 FETCH (UID 1781 FLAGS (%Seen gnus-expire))
* 97 FETCH (UID 1782 FLAGS (%Seen gnus-expire))
* 98 FETCH (UID 1783 FLAGS (%Seen gnus-expire))
* 99 FETCH (UID 1784 FLAGS (%Seen gnus-expire))
* 100 FETCH (UID 1785 FLAGS (%Seen gnus-expire))
* 101 FETCH (UID 1786 FLAGS (%Seen gnus-expire))
* 102 FETCH (UID 1787 FLAGS (%Seen gnus-expire))
* 103 FETCH (UID 1788 FLAGS (%Seen gnus-expire))
* 104 FETCH (UID 1789 FLAGS (%Seen gnus-expire))
* 105 FETCH (UID 1790 FLAGS (%Seen gnus-expire))
* 106 FETCH (UID 1791 FLAGS (%Seen gnus-expire))
* 107 FETCH (UID 1792 FLAGS (%Seen gnus-expire))
* 108 FETCH (UID 1793 FLAGS (%Seen gnus-expire))
* 109 FETCH (UID 1794 FLAGS (%Seen gnus-expire))
* 110 FETCH (UID 1795 FLAGS (%Seen gnus-expire))
* 111 FETCH (UID 1796 FLAGS (%Seen gnus-expire))
* 112 FETCH (UID 1797 FLAGS (%Seen gnus-expire))
* 113 FETCH (UID 1798 FLAGS (%Seen gnus-expire))
184 OK Fetch completed.

Dan

Re: all nnimap flags lost again

[Lars Magne Ingebrigtsen]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> There must be a basic marks parsing problem now. 

Non-standard flags (gnus-*) weren't synced from the server to Gnus after
the `read' makeover.  I've now fixed and pushed this.

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: all nnimap flags lost again

[Lars Magne Ingebrigtsen]

Dan Christensen <jdc@uwo.ca> writes:

>> There must be a basic marks parsing problem now.  Can you send the
>> complete contents of the *nnimap ... * buffer after doing one `M-g' on
>> the group?
>
> Can you increase the size of that buffer, as it often doesn't contain
> the results from a single action?  I switched groups here to another
> one "root" which shows the same problem, and just a bit at the beginning
> is truncated.

The buffer shouldn't be truncated -- a `M-g' just issues a SELECT and a
FETCH FLAGS:

> * FLAGS (%Answered %Flagged %Deleted %Seen %Draft gnus-expire gnus-dormant)
> * OK [PERMANENTFLAGS (%Answered %Flagged %Deleted %Seen %Draft gnus-expire gnus-dormant %*)] Flags permitted.
> * 113 EXISTS
> * 0 RECENT
> * OK [UIDVALIDITY 1256067223] UIDs valid
> * OK [UIDNEXT 1799] Predicted next UID
> 183 OK [READ-WRITE] Select completed.
> * 1 FETCH (UID 757 FLAGS (%Seen))

[...]

> * 112 FETCH (UID 1797 FLAGS (%Seen gnus-expire))
> * 113 FETCH (UID 1798 FLAGS (%Seen gnus-expire))
> 184 OK Fetch completed.

And that looks like the complete response from the SELECT and the
FLAGS.  The IMAP response protocol is slightly unusual -- it first
issues a lot of data on lines that start with "*", and then the numbered
response line ends the response, instead of the other way around, which
is how most other protocols do it.  I think the IMAP way makes more
sense -- you don't have to add an explicit end-of-response line, since
the numbered status line ends the response.

Anyway, everything looks OK in the buffer, and the fix I just pushed
should fix the problem if you `M-g' the affected groups.

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: all nnimap flags lost again

[Dan Christensen]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> Dan Christensen <jdc@uwo.ca> writes:
>
>> Can you increase the size of that buffer, as it often doesn't contain
>> the results from a single action?  
>
> The buffer shouldn't be truncated -- a `M-g' just issues a SELECT and a
> FETCH FLAGS:
>
>> * FLAGS (%Answered %Flagged %Deleted %Seen %Draft gnus-expire gnus-dormant)
>> * OK [PERMANENTFLAGS (%Answered %Flagged %Deleted %Seen %Draft gnus-expire gnus-dormant %*)] Flags permitted.
>> * 113 EXISTS
>> * 0 RECENT
>> * OK [UIDVALIDITY 1256067223] UIDs valid
>> * OK [UIDNEXT 1799] Predicted next UID
>> 183 OK [READ-WRITE] Select completed.

Before I did the `M-g', the buffer showed the response to command 181,
so I thought 182 was missing.  And 181 certainly went missing.  So
old stuff definitely disappears from that buffer, making it hard to
see what happened a few minutes ago.

> Anyway, everything looks OK in the buffer, and the fix I just pushed
> should fix the problem if you `M-g' the affected groups.

It seems to have worked, although somehow in the process some of the
! and ? marks really did lost.  Oh, well.

I wrote:

> Also, I don't know if it's related, but when I hit SPC on an nnimap
> group right after starting Gnus, it only shows me the articles whose
> numbers are within 100 of the most recent.  I was hoping that the trick
> of just looking at the last 100 would be completely internal.

I guess that was unrelated, but it is happening.

Dan

Re: all nnimap flags lost again

[Lars Magne Ingebrigtsen]

Dan Christensen <jdc@uwo.ca> writes:

> Before I did the `M-g', the buffer showed the response to command 181,
> so I thought 182 was missing.  And 181 certainly went missing.  So
> old stuff definitely disappears from that buffer, making it hard to
> see what happened a few minutes ago.

The buffer only contains the last command.  (FSVO "last command" -- the
streaming ones don't delete anything.)  So it's not a log buffer, but a
buffer used for internal parsing.

>> Anyway, everything looks OK in the buffer, and the fix I just pushed
>> should fix the problem if you `M-g' the affected groups.
>
> It seems to have worked, although somehow in the process some of the
> ! and ? marks really did lost.  Oh, well.

Huh.  I wonder how that happened...

>> Also, I don't know if it's related, but when I hit SPC on an nnimap
>> group right after starting Gnus, it only shows me the articles whose
>> numbers are within 100 of the most recent.  I was hoping that the trick
>> of just looking at the last 100 would be completely internal.
>
> I guess that was unrelated, but it is happening.

Does the group show, like, a lot more unread articles in the group
buffer, but you only get the 100 last articles when you enter the group?

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: all nnimap flags lost again

[Dan Christensen]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

>>> Also, I don't know if it's related, but when I hit SPC on an nnimap
>>> group right after starting Gnus, it only shows me the articles whose
>>> numbers are within 100 of the most recent.  I was hoping that the trick
>>> of just looking at the last 100 would be completely internal.
>>
>> I guess that was unrelated, but it is happening.
>
> Does the group show, like, a lot more unread articles in the group
> buffer, but you only get the 100 last articles when you enter the group?

The group had 128 articles, half of which were ticked and the rest of
which were read.  The *Group* buffer correctly showed 64!, but when I
entered, I was only shown 100 articles, with about 50 ticked and 50
read.

I just tried `M-g', entered the group, marked the oldest unread,
exited, quit gnus, and restarted.  Now `SPC' *does* show me all 128
articles.  And this persists even if I change that article back to
being ticked and restart gnus again...  So I can't reproduce with
that group anymore.  But the problem still happens with other
groups on that server.  I have one where every article is marked as
read and there are no other marks (since they were lost...ahem :-).

Dan

Re: all nnimap flags lost again

[Lars Magne Ingebrigtsen]

Dan Christensen <jdc@uwo.ca> writes:

> I just tried `M-g', entered the group, marked the oldest unread,
> exited, quit gnus, and restarted.  Now `SPC' *does* show me all 128
> articles.  And this persists even if I change that article back to
> being ticked and restart gnus again...  So I can't reproduce with
> that group anymore.  But the problem still happens with other
> groups on that server.  I have one where every article is marked as
> read and there are no other marks (since they were lost...ahem :-).

Ahem.

If `M-g' fixes it on that group, could this just be remains of the
previous bugs on the other groups?  If you `M-g' all the groups, are
they all OK?

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: all nnimap flags lost again

[Dan Christensen]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> If `M-g' fixes it on that group, could this just be remains of the
> previous bugs on the other groups?  If you `M-g' all the groups, are
> they all OK?

For a second I thought you were right, but after exiting emacs and
restarting a couple of times, that group with 128 articles is now
only showing 100 after starting Gnus.  So this isn't 100% reproducible,
but more like 50% it seems.

Dan

Re: all nnimap flags lost again

[Dan Christensen]

Is

  gnus-fixup-nnimap-unread-after-getting-new-news

still supposed to be in

  gnus-after-getting-new-news-hook

?  That was something added because the old nnimap had trouble
with unread counts (and it didn't fix the problems for me).
It's in the hook by default: gnus-start.el

Dan

Re: all nnimap flags lost again

[Lars Magne Ingebrigtsen]

Dan Christensen <jdc@uwo.ca> writes:

> Is
>
>   gnus-fixup-nnimap-unread-after-getting-new-news
>
> still supposed to be in
>
>   gnus-after-getting-new-news-hook

Nope.  I've now removed it.  Could it have been causing these problems?
Seems unlikely...

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: all nnimap flags lost again

[Lars Magne Ingebrigtsen]

Dan Christensen <jdc@uwo.ca> writes:

> For a second I thought you were right, but after exiting emacs and
> restarting a couple of times, that group with 128 articles is now
> only showing 100 after starting Gnus.  So this isn't 100% reproducible,
> but more like 50% it seems.

How annoying.  I'm not seeing this at all.

Could you post the `G E' on a group after `M-g' (so that it's as it
should be), and then `G E' when it starts flaking out?  That may give me
a clue to what's going on.

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: all nnimap flags lost again

[Dan Christensen]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> Could you post the `G E' on a group after `M-g' (so that it's as it
> should be), and then `G E' when it starts flaking out?  That may give me
> a clue to what's going on.

First I've included the output of `G E' on my Sent group after starting
Gnus.  Only the recent articles show up when entering the group.

Then I've included the output after hitting `M-g', so all articles are
visible.  Note that once I've done `M-g', things are good until I exit
and restart Gnus.

If you ignore the order of the data, the only difference is that there
is no (active 67 . 3689) in the first output.

I'm running git from yesterday.  If you think it would be helpful (and
safe) to redo this test after upgrading to current git, let me know.

Dan

("nnimap+rocky:Sent" 1
 ((1 . 3689))
 ((seen 3563 3565 3567 3569
	(3572 . 3573)
	(3575 . 3579)
	3581 3583 3585
	(3589 . 3591)
	3593 3595 3597 3599
	(3603 . 3605)
	3607
	(3610 . 3618)
	(3620 . 3621)
	3623 3625 3627 3629
	(3631 . 3632)
	(3635 . 3636)
	(3639 . 3640)
	3642 3644 3646 3648 3650
	(3653 . 3654)
	(3658 . 3661)
	3663
	(3665 . 3677)
	3679
	(3681 . 3684)
	3686
	(3688 . 3689))
  (expire 3385 3387 3389 3392 3397 3399 3402 3406 3413
	  (3416 . 3417)
	  3424 3445 3447 3457 3459 3467 3480
	  (3489 . 3490)
	  3499 3502 3509 3513
	  (3516 . 3517)
	  3521 3523
	  (3527 . 3529)
	  (3531 . 3532)
	  3534 3536 3538 3542
	  (3544 . 3545)
	  3547 3549 3553 3559
	  (3578 . 3579)
	  3585 3589 3591 3593 3595 3597 3599
	  (3603 . 3605)
	  3607
	  (3610 . 3611)
	  3620 3623 3625 3627 3629 3631
	  (3635 . 3636)
	  (3639 . 3640)
	  3642 3644 3646 3648 3650
	  (3653 . 3654)
	  (3658 . 3659)
	  3661 3663 3665 3679 3681)
  (reply 2316 2353 3672))
 "nnimap:rocky"
 ((uidvalidity . "1256067219")))

("nnimap+rocky:Sent" 1
 ((1 . 3689))
 ((expire 3385 3387 3389 3392 3397 3399 3402 3406 3413
	  (3416 . 3417)
	  3424 3445 3447 3457 3459 3467 3480
	  (3489 . 3490)
	  3499 3502 3509 3513
	  (3516 . 3517)
	  3521 3523
	  (3527 . 3529)
	  (3531 . 3532)
	  3534 3536 3538 3542
	  (3544 . 3545)
	  3547 3549 3553 3559
	  (3578 . 3579)
	  3585 3589 3591 3593 3595 3597 3599
	  (3603 . 3605)
	  3607
	  (3610 . 3611)
	  3620 3623 3625 3627 3629 3631
	  (3635 . 3636)
	  (3639 . 3640)
	  3642 3644 3646 3648 3650
	  (3653 . 3654)
	  (3658 . 3659)
	  3661 3663 3665 3679 3681)
  (reply 2316 2353 3672)
  (active 67 . 3689)
  (seen 3563 3565 3567 3569
	(3572 . 3573)
	(3575 . 3579)
	3581 3583 3585
	(3589 . 3591)
	3593 3595 3597 3599
	(3603 . 3605)
	3607
	(3610 . 3618)
	(3620 . 3621)
	3623 3625 3627 3629
	(3631 . 3632)
	(3635 . 3636)
	(3639 . 3640)
	3642 3644 3646 3648 3650
	(3653 . 3654)
	(3658 . 3661)
	3663
	(3665 . 3677)
	3679
	(3681 . 3684)
	3686
	(3688 . 3689)))
 "nnimap:rocky"
 ((uidvalidity . "1256067219")))

Re: all nnimap flags lost again

[Lars Magne Ingebrigtsen]

Dan Christensen <jdc@uwo.ca> writes:

> If you ignore the order of the data, the only difference is that there
> is no (active 67 . 3689) in the first output.

That's really intriguing.  What on earth could be removing the active
entries from the Gnus info?

> I'm running git from yesterday.  If you think it would be helpful (and
> safe) to redo this test after upgrading to current git, let me know.

I'm really mystified here.  You have no special code or settings that
alter the infos in any way -- from a hook, or any other settings that
deal with marks or flags or something?

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: all nnimap flags lost again

[Dan Christensen]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> Dan Christensen <jdc@uwo.ca> writes:
>
>> If you ignore the order of the data, the only difference is that there
>> is no (active 67 . 3689) in the first output.
>
> That's really intriguing.  What on earth could be removing the active
> entries from the Gnus info?

No idea.  Can you recommend what functions I should step through during
Gnus start-up to figure out what is happening?

>> I'm running git from yesterday.  If you think it would be helpful (and
>> safe) to redo this test after upgrading to current git, let me know.
>
> I'm really mystified here.  You have no special code or settings that
> alter the infos in any way -- from a hook, or any other settings that
> deal with marks or flags or something?

Not that I can think of, but I do have a lot of cruft, so if I'm the
only one experiencing this, it's probably something local to my set-up.
I'll try to investigate it more closely over the next few days.

Dan

Re: all nnimap flags lost again

[Lars Magne Ingebrigtsen]

Dan Christensen <jdc@uwo.ca> writes:

> No idea.  Can you recommend what functions I should step through during
> Gnus start-up to figure out what is happening?

The only function that's supposed to meddle with the active entry in the
marks is `nnimap-update-info'.  But I can't see anywhere in the code
where it could potentially wipe out the active entry...

> Not that I can think of, but I do have a lot of cruft, so if I'm the
> only one experiencing this, it's probably something local to my set-up.
> I'll try to investigate it more closely over the next few days.

Ok; good.

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen