* bug#9243: 24.0.50; Gnus keeps seeing 101 unread spam
@ 2011-08-04 20:39 Stefan Monnier
2011-08-21 20:35 ` Lars Magne Ingebrigtsen
0 siblings, 1 reply; 28+ messages in thread
From: Stefan Monnier @ 2011-08-04 20:39 UTC (permalink / raw)
To: 9243
Package: emacs,gnus
[ I have a couple long standing issues that were introduced with the new
nnimap.el code, and it's really high time I bring them up as
bug reports.
Here's the first one, it's one that really doesn't bother me much
(since oddly enough it only affects my `spam' folder) but seems
potentially serious and has the key property of being easy to reproduce,
contrary to some of the other problems I often bump into and which I'll
hence report later. ]
Here's what I did:
- emacs-trunk/src/emacs -f gnus
- type my IMAP password.
- see "101: nnimap+diro:spam" among the folders with unread email.
- Erase *imap log*
- type `g' to refresh the *Group* buffer.
[ it still says "101". ]
- hit `c y' on that folder.
[ it now says "0" unread email in the spam folder. ]
- hit `g' for the fun of it.
[ Lo and behold I have 101 unread email in my spam folder again. ]
And yes, it's always one hundred and one (actually I think
I occasionally see 40k unread email in that folder, maybe if I first
enter it rather than just doing `c y', but that's rare anyway).
You can find below my sig the list of commands sent to the server, with
2 empty lines to separate the `g', the `c y', and the `g'.
Stefan
16:27:41 28 SELECT ""
16:27:41 29 UID FETCH 1:* FLAGS
16:27:41 30 EXAMINE "spam"
16:27:41 31 UID FETCH 46421:* FLAGS
16:27:41 32 EXAMINE "yale"
16:27:41 33 UID FETCH 1140:* FLAGS
16:27:41 34 EXAMINE "types"
16:27:41 35 UID FETCH 3626:* FLAGS
16:27:41 36 EXAMINE "subscriptions"
16:27:41 37 UID FETCH 1:* FLAGS
16:27:41 38 EXAMINE "qcpls"
16:27:41 39 UID FETCH 3266:* FLAGS
16:27:41 40 EXAMINE "friends"
16:27:41 41 UID FETCH 1865:* FLAGS
16:27:41 42 EXAMINE "emacs"
16:27:41 43 UID FETCH 176373:* FLAGS
16:27:41 44 EXAMINE "stages"
16:27:41 45 UID FETCH 1658:* FLAGS
16:27:41 46 EXAMINE "nanda"
16:27:41 47 UID FETCH 1179:* FLAGS
16:27:41 48 EXAMINE "diro"
16:27:41 49 UID FETCH 24052:* FLAGS
16:27:41 50 EXAMINE "cours"
16:27:41 51 UID FETCH 4003:* FLAGS
16:27:41 52 EXAMINE "INBOX"
16:27:41 53 UID FETCH 63343:* FLAGS
16:27:55 54 SELECT "spam"
16:27:55 55 UID STORE 46421:46521 +FLAGS.SILENT (\Seen)
16:27:59 56 SELECT ""
16:27:59 57 UID FETCH 1:* FLAGS
16:27:59 58 EXAMINE "spam"
16:27:59 59 UID FETCH 46421:* FLAGS
16:27:59 60 EXAMINE "yale"
16:27:59 61 UID FETCH 1140:* FLAGS
16:27:59 62 EXAMINE "types"
16:27:59 63 UID FETCH 3626:* FLAGS
16:27:59 64 EXAMINE "subscriptions"
16:27:59 65 UID FETCH 1:* FLAGS
16:27:59 66 EXAMINE "qcpls"
16:27:59 67 UID FETCH 3266:* FLAGS
16:27:59 68 EXAMINE "friends"
16:27:59 69 UID FETCH 1865:* FLAGS
16:27:59 70 EXAMINE "emacs"
16:27:59 71 UID FETCH 176373:* FLAGS
16:27:59 72 EXAMINE "stages"
16:27:59 73 UID FETCH 1658:* FLAGS
16:27:59 74 EXAMINE "nanda"
16:27:59 75 UID FETCH 1179:* FLAGS
16:27:59 76 EXAMINE "diro"
16:27:59 77 UID FETCH 24052:* FLAGS
16:27:59 78 EXAMINE "cours"
16:27:59 79 UID FETCH 4003:* FLAGS
16:27:59 80 EXAMINE "INBOX"
16:27:59 81 UID FETCH 63343:* FLAGS
In GNU Emacs 24.0.50.1 (i686-pc-linux-gnu, GTK+ Version 2.24.4)
of 2011-08-03 on ceviche
Windowing system distributor `The X.Org Foundation', version 11.0.11002000
configured using `configure 'CFLAGS=-Wall -Wno-pointer-sign -DUSE_LISP_UNION_TYPE -DSYNC_INPUT -DENABLE_CHECKING -DXASSERTS -DFONTSET_DEBUG -g -O0 -I/usr/include/GNUstep''
Important settings:
value of $LC_ALL: nil
value of $LC_COLLATE: nil
value of $LC_CTYPE: nil
value of $LC_MESSAGES: nil
value of $LC_MONETARY: nil
value of $LC_NUMERIC: nil
value of $LC_TIME: nil
value of $LANG: fr_CH.UTF-8
value of $XMODIFIERS: nil
locale-coding-system: utf-8-unix
default enable-multibyte-characters: t
Major mode: Group
Minor modes in effect:
gnus-undo-mode: t
electric-pair-mode: t
electric-indent-mode: t
url-handler-mode: t
global-reveal-mode: t
reveal-mode: t
auto-insert-mode: t
savehist-mode: t
minibuffer-electric-default-mode: t
mouse-wheel-mode: t
menu-bar-mode: t
file-name-shadow-mode: t
global-font-lock-mode: t
font-lock-mode: t
auto-composition-mode: t
auto-encryption-mode: t
auto-compression-mode: t
line-number-mode: t
transient-mark-mode: t
Recent input:
<return> n <select-window> <select-window> C-x 5 b
* i m <tab> <return> C-x h C-w <switch-frame> g <down>
<down> <down> <down> <down> <down> <down> <down> <down>
<down> <down> <down> <down> <down> <down> <down> <switch-frame>
<down-mouse-1> <mouse-movement> <mouse-1> C-q C-j <switch-frame>
c y <switch-frame> <down-mouse-1> <mouse-movement>
<mouse-1> C-q C-j <switch-frame> g s <switch-frame>
C-x h M-w <switch-frame> M-x r e p o - e m - b u <tab>
<return>
Recent messages:
Reading active file via nndraft...done
Checking new news...done
Saving /home/monnier/var/newsrc.eld...
Saving file /home/monnier/var/newsrc.eld...
Wrote /home/monnier/var/newsrc.eld
Saving /home/monnier/var/newsrc.eld...done
Mark set [2 times]
Saved text until ""
16:27:59 81 UID FETCH 63343:* FLAGS
"
Load-path shadows:
None found.
Features:
(shadow sort mail-extr emacsbug executable copyright nndraft nnmh utf-7
rfc2104 gnutls network-stream starttls nnimap parse-time tls utf7 netrc
nnagent nnml gnus-agent gnus-srvr gnus-score score-mode nnvirtual
gnus-msg gnus-art mm-uu mml2015 epg-config mm-view mml-smime smime dig
mailcap nntp gnus-cache nnir gnus-sum nnoo gnus-group gnus-undo nnmail
mail-source server gnus-start gnus-spec gnus-int gnus-range message
format-spec rfc822 mml mml-sec mm-decode mm-bodies mm-encode mail-parse
rfc2231 rfc2047 rfc2045 ietf-drums mailabbrev gmm-utils mailheader
gnus-win gnus gnus-ems nnheader mail-utils wid-edit noutline outline
easy-mmode flyspell ispell eldoc checkdoc regexp-opt thingatpt help-mode
view load-dir electric url-handlers url-parse auth-source eieio byte-opt
bytecomp byte-compile cconv macroexp assoc gnus-util password-cache
url-vars mm-util mail-prsvr reveal autoinsert uniquify advice help-fns
advice-preload savehist minibuf-eldef disp-table cl all-autoloads
company-autoloads debbugs-autoloads epoch-view-autoloads
js2-mode-autoloads load-dir-autoloads markchars-autoloads
minimap-autoloads muse-autoloads info easymenu rainbow-mode-autoloads
register-list-autoloads sisu-mode-autoloads uni-confusables-autoloads
windresize-autoloads package tabulated-list proof-site proof-autoloads
pg-vars bbdb-autoloads agda2 time-date tooltip ediff-hook vc-hooks
lisp-float-type mwheel x-win x-dnd tool-bar dnd fontset image fringe
lisp-mode register page menu-bar rfn-eshadow timer select scroll-bar
mouse jit-lock font-lock syntax facemenu font-core frame cham georgian
utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao korean
japanese hebrew greek romanian slovak czech european ethiopic indian
cyrillic chinese case-table epa-hook jka-cmpr-hook help simple abbrev
minibuffer loaddefs button faces cus-face files text-properties overlay
sha1 md5 base64 format env code-pages mule custom widget
hashtable-print-readable backquote make-network-process dbusbind
dynamic-setting system-font-setting font-render-setting move-toolbar gtk
x-toolkit x multi-tty emacs)
^ permalink raw reply [flat|nested] 28+ messages in thread
* bug#9243: 24.0.50; Gnus keeps seeing 101 unread spam
2011-08-04 20:39 bug#9243: 24.0.50; Gnus keeps seeing 101 unread spam Stefan Monnier
@ 2011-08-21 20:35 ` Lars Magne Ingebrigtsen
2011-08-22 22:30 ` Stefan Monnier
0 siblings, 1 reply; 28+ messages in thread
From: Lars Magne Ingebrigtsen @ 2011-08-21 20:35 UTC (permalink / raw)
To: Stefan Monnier; +Cc: 9243
Stefan Monnier <monnier@iro.umontreal.ca> writes:
> Here's what I did:
> - emacs-trunk/src/emacs -f gnus
> - type my IMAP password.
> - see "101: nnimap+diro:spam" among the folders with unread email.
> - Erase *imap log*
> - type `g' to refresh the *Group* buffer.
> [ it still says "101". ]
> - hit `c y' on that folder.
> [ it now says "0" unread email in the spam folder. ]
> - hit `g' for the fun of it.
> [ Lo and behold I have 101 unread email in my spam folder again. ]
Hm. What happens if you `M-g' the group once?
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog http://lars.ingebrigtsen.no/
^ permalink raw reply [flat|nested] 28+ messages in thread
* bug#9243: 24.0.50; Gnus keeps seeing 101 unread spam
2011-08-21 20:35 ` Lars Magne Ingebrigtsen
@ 2011-08-22 22:30 ` Stefan Monnier
2011-09-10 18:58 ` Lars Magne Ingebrigtsen
0 siblings, 1 reply; 28+ messages in thread
From: Stefan Monnier @ 2011-08-22 22:30 UTC (permalink / raw)
To: Lars Magne Ingebrigtsen; +Cc: 9243
>> Here's what I did:
>> - emacs-trunk/src/emacs -f gnus
>> - type my IMAP password.
>> - see "101: nnimap+diro:spam" among the folders with unread email.
>> - Erase *imap log*
>> - type `g' to refresh the *Group* buffer.
>> [ it still says "101". ]
>> - hit `c y' on that folder.
>> [ it now says "0" unread email in the spam folder. ]
>> - hit `g' for the fun of it.
>> [ Lo and behold I have 101 unread email in my spam folder again. ]
> Hm. What happens if you `M-g' the group once?
After M-g, it says "34987: nnimap+diro:spam".
After that `c y' brings it down to 100, and `g' brings it back up to
the magical 101.
Here's a session where I did M-g, then entered the group to view the
last 10 messages, left the group, re-entered it to view all messages,
left the group (at which point it said "12222: nnimap+diro:spam"), then
`g' again (which brought it up to 12323, a difference of 101), then
re-entered the group and left it again with `c y' to go down to 0, after
which a final `g' brought it back to 101.
If I do another M-g, it comes back up to around 34K again.
I'll be happy to increase the logging details if you tell me how.
Stefan
18:12:33 10478 SELECT ""
18:12:33 10479 UID FETCH 1:* FLAGS
18:12:33 10480 EXAMINE "spam"
18:12:33 10481 UID FETCH 46421:* FLAGS
18:12:33 10482 EXAMINE "yale"
18:12:33 10483 UID FETCH 1140:* FLAGS
18:12:33 10484 EXAMINE "types"
18:12:33 10485 UID FETCH 3645:* FLAGS
18:12:33 10486 EXAMINE "subscriptions"
18:12:33 10487 UID FETCH 1:* FLAGS
18:12:33 10488 EXAMINE "qcpls"
18:12:33 10489 UID FETCH 3285:* FLAGS
18:12:33 10490 EXAMINE "friends"
18:12:33 10491 UID FETCH 1872:* FLAGS
18:12:33 10492 EXAMINE "emacs"
18:12:33 10493 UID FETCH 177460:* FLAGS
18:12:33 10494 EXAMINE "stages"
18:12:33 10495 UID FETCH 1658:* FLAGS
18:12:33 10496 EXAMINE "nanda"
18:12:33 10497 UID FETCH 1182:* FLAGS
18:12:33 10498 EXAMINE "diro"
18:12:33 10499 UID FETCH 24191:* FLAGS
18:12:33 10500 EXAMINE "cours"
18:12:33 10501 UID FETCH 4014:* FLAGS
18:12:33 10502 EXAMINE "INBOX"
18:12:33 10503 UID FETCH 63716:* FLAGS
18:14:24 10504 NOOP
18:14:30 10505 SELECT "spam"
18:14:30 10506 UID FETCH 1:* FLAGS
18:15:31 10507 SELECT ""
18:15:31 10508 UID FETCH 1:* FLAGS
18:15:31 10509 EXAMINE "spam"
18:15:31 10510 UID FETCH 46421:* FLAGS
18:15:31 10511 EXAMINE "yale"
18:15:31 10512 UID FETCH 1140:* FLAGS
18:15:31 10513 EXAMINE "types"
18:15:31 10514 UID FETCH 3645:* FLAGS
18:15:31 10515 EXAMINE "subscriptions"
18:15:31 10516 UID FETCH 1:* FLAGS
18:15:31 10517 EXAMINE "qcpls"
18:15:31 10518 UID FETCH 3285:* FLAGS
18:15:31 10519 EXAMINE "friends"
18:15:31 10520 UID FETCH 1872:* FLAGS
18:15:31 10521 EXAMINE "emacs"
18:15:31 10522 UID FETCH 177487:* FLAGS
18:15:31 10523 EXAMINE "stages"
18:15:31 10524 UID FETCH 1658:* FLAGS
18:15:31 10525 EXAMINE "nanda"
18:15:31 10526 UID FETCH 1182:* FLAGS
18:15:31 10527 EXAMINE "diro"
18:15:31 10528 UID FETCH 24193:* FLAGS
18:15:31 10529 EXAMINE "cours"
18:15:31 10530 UID FETCH 4014:* FLAGS
18:15:31 10531 EXAMINE "INBOX"
18:15:31 10532 UID FETCH 63719:* FLAGS
18:16:48 10560 SELECT "spam"
18:16:55 10561 UID STORE 46512:46521 +FLAGS.SILENT (\Seen)
18:18:36 10562 NOOP
18:18:39 10563 UID STORE 12319:12320,12444:12447,13514:13517,13749:13750,13862,13936:13943,13971,14092,15263:15264,17444:17448,19595:24529,24562:25728,25912:26214,26257:26521,26536:26797,26889:29232,29298:30019,30511:30836,30840,30874:30990,30994:31009,31031:31035,31046,31081:31088,31095:31320,31493:31515,31522:31527,31534:31539,31575:31633,31649:31665,31673:31775,31788:31793,31795:31986,32013:32088,32090:32187,32196:32202,32212:32217,32224:32227,32246:32249,32275:32328,32349:32401,32403:32451,32458:32468,32471:32479,32481,32483,32488:32510,32520:32530,32532:32540,32565:32579,32591:32592,32600:32601,32623:32701,32713:32721,32734:32739,32751:32826,32834:32838,32871:32875,32882,32890:33003,33012:33022,33030:33036,33051:33063,33108:33134,33138:33194,33210:33219,33247:33265,33276:33310,33322:33332,33335:33343,33355:33372,33425:33441,33443:33488,33490:33494,33514,33525:33567,33639:33706,33738:33799,33831:34089,34143:34164,34175:34278,34313:34331,34373:34469,34493:34551,34556:34575,34578:34581,34618:34621,34625:34707,34766:34814,34820:35223,35281:35328,35340:35629,35649:35721,35789:35804,35808:35986,36116:36169,36177:36293,36301:36324,36378:36412,36425:36440,36467:36485,36503:36627,36693:36721,36750:36762,36823:36835,36854:36864,36883:37020,37040:37053,37135:37150,37257:37351,37373:37377,37384:37401,37544:37574,37610:37772,37827:37875,37886:37960,37980,37982,38005:38020,38085:38151,38227:38247,38288:38338,38354:38432,38467:38492,38528:38533,38623:38626,38632:38689,38726:38748,38807:39085,39140:39156,39178:39706,39732:42413,42419:42622,42772:43403,43433:43476,43506:43772,43788:43798,43815:43834,43881:43915,43923:45919,45946:46511 +FLAGS.SILENT (\Seen)
18:19:02 10564 SELECT ""
18:19:02 10565 UID FETCH 1:* FLAGS
18:19:02 10566 EXAMINE "spam"
18:19:02 10567 UID FETCH 46421:* FLAGS
18:19:02 10568 EXAMINE "yale"
18:19:02 10569 UID FETCH 1140:* FLAGS
18:19:02 10570 EXAMINE "types"
18:19:02 10571 UID FETCH 3645:* FLAGS
18:19:02 10572 EXAMINE "subscriptions"
18:19:02 10573 UID FETCH 1:* FLAGS
18:19:02 10574 EXAMINE "qcpls"
18:19:02 10575 UID FETCH 3285:* FLAGS
18:19:02 10576 EXAMINE "friends"
18:19:02 10577 UID FETCH 1872:* FLAGS
18:19:02 10578 EXAMINE "emacs"
18:19:02 10579 UID FETCH 177488:* FLAGS
18:19:02 10580 EXAMINE "stages"
18:19:02 10581 UID FETCH 1658:* FLAGS
18:19:02 10582 EXAMINE "nanda"
18:19:02 10583 UID FETCH 1182:* FLAGS
18:19:02 10584 EXAMINE "diro"
18:19:02 10585 UID FETCH 24193:* FLAGS
18:19:02 10586 EXAMINE "cours"
18:19:02 10587 UID FETCH 4014:* FLAGS
18:19:02 10588 EXAMINE "INBOX"
18:19:02 10589 UID FETCH 63719:* FLAGS
18:19:37 10590 SELECT "spam"
18:21:12 10591 NOOP
18:23:50 10592 UID STORE 11535:12318,12321:12443,12448:13513,13518:13748,13751:13861,13863:13935,13944:13970,13972:14091,14093:15262,15265:17443,17449:19594,24530:24561,25729:25911,26215:26256,26522:26535,26798:26888,29233:29297,30020:30510,30837:30839,30841:30873,30991:30993,31010:31030,31036:31045,31047:31080,31089:31094,31321:31492,31516:31521,31528:31533,31540:31574,31634:31648,31666:31672,31776:31787,31794,31987:32012,32089,32188:32195,32203:32211,32218:32223,32228:32245,32250:32274,32329:32348,32402,32452:32457,32469:32470,32480,32482,32484:32487,32511:32519,32531,32541:32564,32580:32590,32593:32599,32602:32622,32702:32712,32722:32733,32740:32750,32827:32833,32839:32870,32876:32881,32883:32889,33004:33011,33023:33029,33037:33050,33064:33107,33135:33137,33195:33209,33220:33246,33266:33275,33311:33321,33333:33334,33344:33354,33373:33424,33442,33489,33495:33513,33515:33524,33568:33638,33707:33737,33800:33830,34090:34142,34165:34174,34279:34312,34332:34372,34470:34492,34552:34555,34576:34577,34582:34617,34622:34624,34708:34765,34815:34819,35224:35280,35329:35339,35630:35648,35722:35788,35805:35807,35987:36115,36170:36176,36294:36300,36325:36377,36413:36424,36441:36466,36486:36502,36628:36692,36722:36749,36763:36822,36836:36853,36865:36882,37021:37039,37054:37134,37151:37256,37352:37372,37378:37383,37402:37543,37575:37609,37773:37826,37876:37885,37961:37979,37981,37983:38004,38021:38084,38152:38226,38248:38287,38339:38353,38433:38466,38493:38527,38534:38622,38627:38631,38690:38725,38749:38806,39086:39139,39157:39177,39707:39731,42414:42418,42623:42771,43404:43432,43477:43505,43773:43787,43799:43814,43835:43880,43916:43922,45920:45945,46421:46521 +FLAGS.SILENT (\Seen)
18:23:50 10593 NOOP
18:24:00 10594 SELECT ""
18:24:00 10595 UID FETCH 1:* FLAGS
18:24:00 10596 EXAMINE "spam"
18:24:00 10597 UID FETCH 46421:* FLAGS
18:24:00 10598 EXAMINE "yale"
18:24:00 10599 UID FETCH 1140:* FLAGS
18:24:00 10600 EXAMINE "types"
18:24:00 10601 UID FETCH 3645:* FLAGS
18:24:00 10602 EXAMINE "subscriptions"
18:24:00 10603 UID FETCH 1:* FLAGS
18:24:00 10604 EXAMINE "qcpls"
18:24:00 10605 UID FETCH 3285:* FLAGS
18:24:00 10606 EXAMINE "friends"
18:24:00 10607 UID FETCH 1872:* FLAGS
18:24:00 10608 EXAMINE "emacs"
18:24:00 10609 UID FETCH 177489:* FLAGS
18:24:00 10610 EXAMINE "stages"
18:24:00 10611 UID FETCH 1658:* FLAGS
18:24:00 10612 EXAMINE "nanda"
18:24:00 10613 UID FETCH 1182:* FLAGS
18:24:00 10614 EXAMINE "diro"
18:24:00 10615 UID FETCH 24193:* FLAGS
18:24:00 10616 EXAMINE "cours"
18:24:00 10617 UID FETCH 4014:* FLAGS
18:24:00 10618 EXAMINE "INBOX"
18:24:00 10619 UID FETCH 63719:* FLAGS
18:24:24 10620 NOOP
^ permalink raw reply [flat|nested] 28+ messages in thread
* bug#9243: 24.0.50; Gnus keeps seeing 101 unread spam
2011-08-22 22:30 ` Stefan Monnier
@ 2011-09-10 18:58 ` Lars Magne Ingebrigtsen
2011-09-13 17:42 ` Stefan Monnier
0 siblings, 1 reply; 28+ messages in thread
From: Lars Magne Ingebrigtsen @ 2011-09-10 18:58 UTC (permalink / raw)
To: Stefan Monnier; +Cc: 9243
Stefan Monnier <monnier@iro.umontreal.ca> writes:
> 18:12:33 10480 EXAMINE "spam"
> 18:12:33 10481 UID FETCH 46421:* FLAGS
It's most puzzling. From the log, your `c' on the group made it set
46421:46721 to \Seen. But it sounds like every time it does the
commands above, it's being told that the last 101 messages are unread
again.
Could you go to the " *nnimap ... " buffer and eval the following?
(process-send-string (get-buffer-process (current-buffer))
"1 EXAMINE spam\r\n2 UID FETCH 46421:* FLAGS\r\n")
Replace the article number with what the imap log says `g' is querying.
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog http://lars.ingebrigtsen.no/
^ permalink raw reply [flat|nested] 28+ messages in thread
* bug#9243: 24.0.50; Gnus keeps seeing 101 unread spam
2011-09-10 18:58 ` Lars Magne Ingebrigtsen
@ 2011-09-13 17:42 ` Stefan Monnier
2011-09-17 5:25 ` Lars Magne Ingebrigtsen
0 siblings, 1 reply; 28+ messages in thread
From: Stefan Monnier @ 2011-09-13 17:42 UTC (permalink / raw)
To: Lars Magne Ingebrigtsen; +Cc: 9243
> Could you go to the " *nnimap ... " buffer and eval the following?
Hmm.. I have 8 of those buffers. Anyway, the 8th seems to have
a running process.
> (process-send-string (get-buffer-process (current-buffer))
> "1 EXAMINE spam\r\n2 UID FETCH 46421:* FLAGS\r\n")
`g' said 46421, so I ran exactly the above command, and the result was:
* 12684 EXISTS
* 52 RECENT
* OK [UIDVALIDITY 1305554723] UID validity status
* OK [UIDNEXT 12685] Predicted next UID
* FLAGS (\Answered \Flagged \Deleted \Draft \Seen)
* OK [PERMANENTFLAGS ()] Permanent flags
* OK [UNSEEN 11634] first unseen message in /export/home/mail3/monnier/Mail/spam
1 OK [READ-ONLY] EXAMINE completed
* 12684 FETCH (UID 12684 FLAGS (\Recent))
2 OK UID FETCH completed
Stefan
^ permalink raw reply [flat|nested] 28+ messages in thread
* bug#9243: 24.0.50; Gnus keeps seeing 101 unread spam
2011-09-13 17:42 ` Stefan Monnier
@ 2011-09-17 5:25 ` Lars Magne Ingebrigtsen
2011-09-17 21:07 ` Stefan Monnier
0 siblings, 1 reply; 28+ messages in thread
From: Lars Magne Ingebrigtsen @ 2011-09-17 5:25 UTC (permalink / raw)
To: Stefan Monnier; +Cc: 9243
Stefan Monnier <monnier@IRO.UMontreal.CA> writes:
>> (process-send-string (get-buffer-process (current-buffer))
>> "1 EXAMINE spam\r\n2 UID FETCH 46421:* FLAGS\r\n")
>
> `g' said 46421, so I ran exactly the above command, and the result was:
>
> * 12684 EXISTS
> * 52 RECENT
> * OK [UIDVALIDITY 1305554723] UID validity status
> * OK [UIDNEXT 12685] Predicted next UID
> * FLAGS (\Answered \Flagged \Deleted \Draft \Seen)
> * OK [PERMANENTFLAGS ()] Permanent flags
> * OK [UNSEEN 11634] first unseen message in /export/home/mail3/monnier/Mail/spam
> 1 OK [READ-ONLY] EXAMINE completed
> * 12684 FETCH (UID 12684 FLAGS (\Recent))
> 2 OK UID FETCH completed
That's really unexpected. The IMAP server claims that the highest
message number is 12684, while Gnus thinks that the highest number is
46520 or something.
Hm. Oh! Are your nnimap groups covered by the Agent? Or are there
cache entries that may interfere here?
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog http://lars.ingebrigtsen.no/
^ permalink raw reply [flat|nested] 28+ messages in thread
* bug#9243: 24.0.50; Gnus keeps seeing 101 unread spam
2011-09-17 5:25 ` Lars Magne Ingebrigtsen
@ 2011-09-17 21:07 ` Stefan Monnier
2011-09-18 7:27 ` Lars Magne Ingebrigtsen
0 siblings, 1 reply; 28+ messages in thread
From: Stefan Monnier @ 2011-09-17 21:07 UTC (permalink / raw)
To: Lars Magne Ingebrigtsen; +Cc: 9243
> That's really unexpected. The IMAP server claims that the highest
> message number is 12684, while Gnus thinks that the highest number is
> 46520 or something.
> Hm. Oh! Are your nnimap groups covered by the Agent? Or are there
> cache entries that may interfere here?
There's an agent, yes. Don't know if there are cache entries nor how to
check it.
Stefan
^ permalink raw reply [flat|nested] 28+ messages in thread
* bug#9243: 24.0.50; Gnus keeps seeing 101 unread spam
2011-09-17 21:07 ` Stefan Monnier
@ 2011-09-18 7:27 ` Lars Magne Ingebrigtsen
2011-09-18 13:48 ` Stefan Monnier
0 siblings, 1 reply; 28+ messages in thread
From: Lars Magne Ingebrigtsen @ 2011-09-18 7:27 UTC (permalink / raw)
To: Stefan Monnier; +Cc: 9243
Stefan Monnier <monnier@iro.umontreal.ca> writes:
> There's an agent, yes.
Right. nnimap and the Agent has a buggy interaction, which I haven't
taken the time to work through properly yet.
> Don't know if there are cache entries nor how to check it.
Look in ~/News/cache/.
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog http://lars.ingebrigtsen.no/
^ permalink raw reply [flat|nested] 28+ messages in thread
* bug#9243: 24.0.50; Gnus keeps seeing 101 unread spam
2011-09-18 7:27 ` Lars Magne Ingebrigtsen
@ 2011-09-18 13:48 ` Stefan Monnier
2011-09-21 18:53 ` Lars Magne Ingebrigtsen
0 siblings, 1 reply; 28+ messages in thread
From: Stefan Monnier @ 2011-09-18 13:48 UTC (permalink / raw)
To: Lars Magne Ingebrigtsen; +Cc: 9243
>> There's an agent, yes.
> Right. nnimap and the Agent has a buggy interaction, which I haven't
> taken the time to work through properly yet.
The Agent is indispensable for nnimap (unless you use offlineimap that
is), and while I do see a few problems with nnimap (which may all come
from the Agent), it's mostly usable, so I think it's worth the trouble
trying to make it work (and enable it by default).
>> Don't know if there are cache entries nor how to check it.
> Look in ~/News/cache/.
I see, then no I have no such thing (I do have gnus-agent-cache
enabled, but that seems to be cached under ~/News/agent instead).
Stefan
^ permalink raw reply [flat|nested] 28+ messages in thread
* bug#9243: 24.0.50; Gnus keeps seeing 101 unread spam
2011-09-18 13:48 ` Stefan Monnier
@ 2011-09-21 18:53 ` Lars Magne Ingebrigtsen
2012-01-06 23:38 ` Lars Magne Ingebrigtsen
0 siblings, 1 reply; 28+ messages in thread
From: Lars Magne Ingebrigtsen @ 2011-09-21 18:53 UTC (permalink / raw)
To: Stefan Monnier; +Cc: 9243
Stefan Monnier <monnier@iro.umontreal.ca> writes:
> The Agent is indispensable for nnimap (unless you use offlineimap that
> is), and while I do see a few problems with nnimap (which may all come
> from the Agent), it's mostly usable, so I think it's worth the trouble
> trying to make it work (and enable it by default).
Yes, of course. I just haven't quite worked up the nerve to go delving
into that code again, but I'm steeling myself, and will get to it one of
these weekends.
> I see, then no I have no such thing (I do have gnus-agent-cache
> enabled, but that seems to be cached under ~/News/agent instead).
Right. So the problem is definitely with the Agent and not the cache,
which is good to know.
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog http://lars.ingebrigtsen.no/
^ permalink raw reply [flat|nested] 28+ messages in thread
* bug#9243: 24.0.50; Gnus keeps seeing 101 unread spam
2011-09-21 18:53 ` Lars Magne Ingebrigtsen
@ 2012-01-06 23:38 ` Lars Magne Ingebrigtsen
2012-01-07 1:05 ` Stefan Monnier
0 siblings, 1 reply; 28+ messages in thread
From: Lars Magne Ingebrigtsen @ 2012-01-06 23:38 UTC (permalink / raw)
To: Stefan Monnier; +Cc: 9243
Lars Magne Ingebrigtsen <larsi@gnus.org> writes:
>> The Agent is indispensable for nnimap (unless you use offlineimap that
>> is), and while I do see a few problems with nnimap (which may all come
>> from the Agent), it's mostly usable, so I think it's worth the trouble
>> trying to make it work (and enable it by default).
>
> Yes, of course. I just haven't quite worked up the nerve to go delving
> into that code again, but I'm steeling myself, and will get to it one of
> these weekends.
I've started looking into this now -- I've enabled the Agent for my main
IMAP server and stuff. But I haven't seen any bugs yet.
Is there anything in particular one does to make the Agent misbehave?
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog http://lars.ingebrigtsen.no/
^ permalink raw reply [flat|nested] 28+ messages in thread
* bug#9243: 24.0.50; Gnus keeps seeing 101 unread spam
2012-01-06 23:38 ` Lars Magne Ingebrigtsen
@ 2012-01-07 1:05 ` Stefan Monnier
2012-01-07 1:39 ` Lars Magne Ingebrigtsen
0 siblings, 1 reply; 28+ messages in thread
From: Stefan Monnier @ 2012-01-07 1:05 UTC (permalink / raw)
To: Lars Magne Ingebrigtsen; +Cc: 9243
> Is there anything in particular one does to make the Agent misbehave?
I wish I knew. I see various occasional problems, but I don't know how
to reproduce them. Just for information, here's the kind of problems
I see:
- seen messages re-appearing as unseen (presumably because the imap
connection died during the "group exit").
- old&seen messages that refuse to appear (they don't show up in the
Summary, tho if I disable the Agent and try again, they show up just
fine).
- different independent machines have different ideas about the number
of unseen messages in a given IMAP folder.
- not sure if it's related, but exiting a group/folder takes forever
(apparently because I ask Gnus to do expiration at that time).
- not sure if it's related, but "B m" to move stuff from a group/folder
to another takes *ages* (as in several minutes), and I think most of
this time is spent in Gnus trying to update its idea of the content of
the destination group (after the actual move took place).
I've already been tempted to setup offlineimap to work around these
problems (after all, having a complete local copy of my mailbox(es)
would be great), but I keep hoping that it will get fixed soon.
Stefan
^ permalink raw reply [flat|nested] 28+ messages in thread
* bug#9243: 24.0.50; Gnus keeps seeing 101 unread spam
2012-01-07 1:05 ` Stefan Monnier
@ 2012-01-07 1:39 ` Lars Magne Ingebrigtsen
2012-01-07 2:45 ` Stefan Monnier
0 siblings, 1 reply; 28+ messages in thread
From: Lars Magne Ingebrigtsen @ 2012-01-07 1:39 UTC (permalink / raw)
To: Stefan Monnier; +Cc: 9243
Stefan Monnier <monnier@iro.umontreal.ca> writes:
> - seen messages re-appearing as unseen (presumably because the imap
> connection died during the "group exit").
That should probably be unrelated to the Agent, and won't be fixed
during this development cycle. To fix this properly, Gnus would have to
maintain a transaction log (on disk) and update the IMAP server in a
"transactional" manner, instead of (as it does now) just sending the
data to the server on Group exit.
> - old&seen messages that refuse to appear (they don't show up in the
> Summary, tho if I disable the Agent and try again, they show up just
> fine).
> - different independent machines have different ideas about the number
> of unseen messages in a given IMAP folder.
Hm...
> - not sure if it's related, but exiting a group/folder takes forever
> (apparently because I ask Gnus to do expiration at that time).
Some IMAP servers are really, really slow at doing expunging on big
folders. They basically keep all the messages in one big file, and they
have to rewrite the entire file to delete a message, if I understand
correctly.
Does setting `nnimap-expunge' to nil make exit fast? In that case,
that's the problem, and if not, I can try do debug...
> - not sure if it's related, but "B m" to move stuff from a group/folder
> to another takes *ages* (as in several minutes), and I think most of
> this time is spent in Gnus trying to update its idea of the content of
> the destination group (after the actual move took place).
Huh. Hm... Actually, can you try the `nnimap-expunge' setting for
this, too?
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog http://lars.ingebrigtsen.no/
^ permalink raw reply [flat|nested] 28+ messages in thread
* bug#9243: 24.0.50; Gnus keeps seeing 101 unread spam
2012-01-07 1:39 ` Lars Magne Ingebrigtsen
@ 2012-01-07 2:45 ` Stefan Monnier
2012-01-07 3:25 ` Lars Magne Ingebrigtsen
0 siblings, 1 reply; 28+ messages in thread
From: Stefan Monnier @ 2012-01-07 2:45 UTC (permalink / raw)
To: Lars Magne Ingebrigtsen; +Cc: 9243
>> - seen messages re-appearing as unseen (presumably because the imap
>> connection died during the "group exit").
> That should probably be unrelated to the Agent, and won't be fixed
> during this development cycle.
AFAIK my use case is not completely unusual (typically connected via
a NAT router to my university's IMAP server) and I see this problem more
or less *every day*.
So I really hope you can try to fix this soon.
FWIW I never saw this problem with the old nnimap backend, so it's
a (very serious if you ask me) regression w.r.t Emacs-23.
And I think it is related to the agent, because the connection death
would be handled differently without the agent: the connection would be
re-established and the command re-tried, whereas with the new
"connection death silently puts the agent in offline mode", the command
just gets dropped on the floor.
> To fix this properly, Gnus would have to maintain a transaction log
> (on disk) and update the IMAP server in a "transactional" manner,
> instead of (as it does now) just sending the data to the server on
> Group exit.
Emacs-23's experience seems to indicate there's a way to get much better
behavior without going to such a transaction log.
> Some IMAP servers are really, really slow at doing expunging on big
> folders. They basically keep all the messages in one big file, and they
> have to rewrite the entire file to delete a message, if I understand
> correctly.
That's probably what's going on (each folder is stored as a large single
file). Can the expunging be done asynchronously?
>> - not sure if it's related, but "B m" to move stuff from a group/folder
>> to another takes *ages* (as in several minutes), and I think most of
>> this time is spent in Gnus trying to update its idea of the content of
>> the destination group (after the actual move took place).
> Huh. Hm... Actually, can you try the `nnimap-expunge' setting for
> this, too?
I'll try it out for a while and will tell you if it gets better,
Stefan
^ permalink raw reply [flat|nested] 28+ messages in thread
* bug#9243: 24.0.50; Gnus keeps seeing 101 unread spam
2012-01-07 2:45 ` Stefan Monnier
@ 2012-01-07 3:25 ` Lars Magne Ingebrigtsen
2012-01-07 3:30 ` Lars Magne Ingebrigtsen
2012-01-10 19:56 ` Stefan Monnier
0 siblings, 2 replies; 28+ messages in thread
From: Lars Magne Ingebrigtsen @ 2012-01-07 3:25 UTC (permalink / raw)
To: Stefan Monnier; +Cc: 9243
Stefan Monnier <monnier@iro.umontreal.ca> writes:
> AFAIK my use case is not completely unusual (typically connected via
> a NAT router to my university's IMAP server) and I see this problem more
> or less *every day*.
> So I really hope you can try to fix this soon.
> FWIW I never saw this problem with the old nnimap backend, so it's
> a (very serious if you ask me) regression w.r.t Emacs-23.
I've had a look at the nnimap in Emacs 23 to see whether I've missed
something, but it looks to me like that nnimap did exactly the same
thing as the Emacs 24 one does: `nnimap-request-set-mark' is called on
group exit, and that's basically it. (Marks are also altered when you
move messages and stuff, but for normal reading,
`nnimap-request-set-mark' on group exit is the main thing.)
So I don't understand how this has changed, really.
> And I think it is related to the agent, because the connection death
> would be handled differently without the agent: the connection would be
> re-established and the command re-tried, whereas with the new
> "connection death silently puts the agent in offline mode", the command
> just gets dropped on the floor.
Oh, yeah, that's a definite possibility. Did you use to get an "go
offline?" query on group exit? In that case, that does sound like a
definite possible culprit, and shouldn't be difficult to reproduce and
fix...
> That's probably what's going on (each folder is stored as a large single
> file). Can the expunging be done asynchronously?
Not fully without opening a second connection to the IMAP server. One
could just send off the "EXPUNGE" and not wait for the result, but it
means that the next IMAP command will have to wait instead, which will
feel like random hangs...
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog http://lars.ingebrigtsen.no/
^ permalink raw reply [flat|nested] 28+ messages in thread
* bug#9243: 24.0.50; Gnus keeps seeing 101 unread spam
2012-01-07 3:25 ` Lars Magne Ingebrigtsen
@ 2012-01-07 3:30 ` Lars Magne Ingebrigtsen
2012-01-07 3:31 ` Lars Magne Ingebrigtsen
2012-01-10 19:56 ` Stefan Monnier
1 sibling, 1 reply; 28+ messages in thread
From: Lars Magne Ingebrigtsen @ 2012-01-07 3:30 UTC (permalink / raw)
To: Stefan Monnier; +Cc: 9243
Lars Magne Ingebrigtsen <larsi@gnus.org> writes:
> Oh, yeah, that's a definite possibility. Did you use to get an "go
> offline?" query on group exit? In that case, that does sound like a
> definite possible culprit, and shouldn't be difficult to reproduce and
> fix...
I thought I could reproduce by
(defun gnutls-available-p () t)
entering an IMAP group, killing gnutls-cli and then exiting, but in that
case Gnus just restarted a new connection and sent the marks over,
unfortunately.
Well, it's nice that it works :-), but it means that it's not that easy
to reproduce...
Hm.
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog http://lars.ingebrigtsen.no/
^ permalink raw reply [flat|nested] 28+ messages in thread
* bug#9243: 24.0.50; Gnus keeps seeing 101 unread spam
2012-01-07 3:30 ` Lars Magne Ingebrigtsen
@ 2012-01-07 3:31 ` Lars Magne Ingebrigtsen
2012-01-07 3:44 ` Lars Magne Ingebrigtsen
0 siblings, 1 reply; 28+ messages in thread
From: Lars Magne Ingebrigtsen @ 2012-01-07 3:31 UTC (permalink / raw)
To: Stefan Monnier; +Cc: 9243
Lars Magne Ingebrigtsen <larsi@gnus.org> writes:
> I thought I could reproduce by
>
> (defun gnutls-available-p () t)
(defun gnutls-available-p () nil)
I mean.
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog http://lars.ingebrigtsen.no/
^ permalink raw reply [flat|nested] 28+ messages in thread
* bug#9243: 24.0.50; Gnus keeps seeing 101 unread spam
2012-01-07 3:31 ` Lars Magne Ingebrigtsen
@ 2012-01-07 3:44 ` Lars Magne Ingebrigtsen
0 siblings, 0 replies; 28+ messages in thread
From: Lars Magne Ingebrigtsen @ 2012-01-07 3:44 UTC (permalink / raw)
To: Stefan Monnier; +Cc: 9243
`gnus-agent-synchronize-flags' has defaulted to nil since 2005, but that
means that marks that have been set while Gnus is offline won't
propagate to the server automatically.
The comment is
;; If the default switches to something else than nil, then the function
;; should be fixed not be exceedingly slow. See 2005-09-20 ChangeLog entry.
but I tried it just now, and it isn't particularly slow. If no marks
have been set, then it doesn't do anything much.
I think the issue was that nntp (for some reason or other) had gotten
backend marks switched on by default, which made things just slow beyond
belief. But now that's not the case, so I think this should default to
t.
Anybody have any thoughts on this?
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog http://lars.ingebrigtsen.no/
^ permalink raw reply [flat|nested] 28+ messages in thread
* bug#9243: 24.0.50; Gnus keeps seeing 101 unread spam
2012-01-07 3:25 ` Lars Magne Ingebrigtsen
2012-01-07 3:30 ` Lars Magne Ingebrigtsen
@ 2012-01-10 19:56 ` Stefan Monnier
2012-01-25 23:35 ` Lars Ingebrigtsen
` (2 more replies)
1 sibling, 3 replies; 28+ messages in thread
From: Stefan Monnier @ 2012-01-10 19:56 UTC (permalink / raw)
To: Lars Magne Ingebrigtsen; +Cc: 9243
After (setq nnimap-expunge nil), the expiry that happens when I leave
a group still takes a good while (I didn't notice any serious
difference), but moving email from one IMAP folder to another with "B m"
is *much* faster.
Stefan
^ permalink raw reply [flat|nested] 28+ messages in thread
* bug#9243: 24.0.50; Gnus keeps seeing 101 unread spam
2012-01-10 19:56 ` Stefan Monnier
@ 2012-01-25 23:35 ` Lars Ingebrigtsen
2012-04-10 21:18 ` Lars Magne Ingebrigtsen
2012-04-10 21:19 ` Lars Magne Ingebrigtsen
2 siblings, 0 replies; 28+ messages in thread
From: Lars Ingebrigtsen @ 2012-01-25 23:35 UTC (permalink / raw)
To: Stefan Monnier; +Cc: 9243
Stefan Monnier <monnier@IRO.UMontreal.CA> writes:
> After (setq nnimap-expunge nil), the expiry that happens when I leave
> a group still takes a good while (I didn't notice any serious
> difference), but moving email from one IMAP folder to another with "B m"
> is *much* faster.
That's kinda odd. They should either both be faster, or none, I'd have
thought.
Could you post the commands output into "*imap log*" upon group exit?
Perhaps Gnus is sending way too many commands on exit or something...
--
(domestic pets only, the antidote for overdose, milk.)
http://lars.ingebrigtsen.no * Sent from my Rome
^ permalink raw reply [flat|nested] 28+ messages in thread
* bug#9243: 24.0.50; Gnus keeps seeing 101 unread spam
2012-01-10 19:56 ` Stefan Monnier
2012-01-25 23:35 ` Lars Ingebrigtsen
@ 2012-04-10 21:18 ` Lars Magne Ingebrigtsen
2012-04-10 21:19 ` Lars Magne Ingebrigtsen
2 siblings, 0 replies; 28+ messages in thread
From: Lars Magne Ingebrigtsen @ 2012-04-10 21:18 UTC (permalink / raw)
To: Stefan Monnier; +Cc: 9243
Stefan Monnier <monnier@IRO.UMontreal.CA> writes:
> After (setq nnimap-expunge nil), the expiry that happens when I leave
> a group still takes a good while (I didn't notice any serious
> difference), but moving email from one IMAP folder to another with "B m"
> is *much* faster.
If this is with a big group, then this has been fixed in Ma Gnus, but
the fix is not applicable for Emacs 24.1. It involves tracking what
messages actually exist on the IMAP server, and not just the low/high
water marks, and is kinda hairy.
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog http://lars.ingebrigtsen.no/
^ permalink raw reply [flat|nested] 28+ messages in thread
* bug#9243: 24.0.50; Gnus keeps seeing 101 unread spam
2012-01-10 19:56 ` Stefan Monnier
2012-01-25 23:35 ` Lars Ingebrigtsen
2012-04-10 21:18 ` Lars Magne Ingebrigtsen
@ 2012-04-10 21:19 ` Lars Magne Ingebrigtsen
2012-04-11 0:56 ` Stefan Monnier
2 siblings, 1 reply; 28+ messages in thread
From: Lars Magne Ingebrigtsen @ 2012-04-10 21:19 UTC (permalink / raw)
To: Stefan Monnier; +Cc: 9243
Anyway, looking over this bug report, I'm not sure we really got
anywhere with the main issue here. Are you still seeing these
discrepancies in article numbers?
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog http://lars.ingebrigtsen.no/
^ permalink raw reply [flat|nested] 28+ messages in thread
* bug#9243: 24.0.50; Gnus keeps seeing 101 unread spam
2012-04-10 21:19 ` Lars Magne Ingebrigtsen
@ 2012-04-11 0:56 ` Stefan Monnier
2012-09-05 18:07 ` Lars Ingebrigtsen
0 siblings, 1 reply; 28+ messages in thread
From: Stefan Monnier @ 2012-04-11 0:56 UTC (permalink / raw)
To: Lars Magne Ingebrigtsen; +Cc: 9243
> Anyway, looking over this bug report, I'm not sure we really got
> anywhere with the main issue here. Are you still seeing these
> discrepancies in article numbers?
Oh, yes. Actually, I now see something similar with comp.lang.ml
accessed via NNTP (additionally to the spam folder accessed over imap).
Stefan
^ permalink raw reply [flat|nested] 28+ messages in thread
* bug#9243: 24.0.50; Gnus keeps seeing 101 unread spam
2012-04-11 0:56 ` Stefan Monnier
@ 2012-09-05 18:07 ` Lars Ingebrigtsen
2012-09-05 19:12 ` Stefan Monnier
0 siblings, 1 reply; 28+ messages in thread
From: Lars Ingebrigtsen @ 2012-09-05 18:07 UTC (permalink / raw)
To: Stefan Monnier; +Cc: 9243
Stefan Monnier <monnier@iro.umontreal.ca> writes:
>> Anyway, looking over this bug report, I'm not sure we really got
>> anywhere with the main issue here. Are you still seeing these
>> discrepancies in article numbers?
>
> Oh, yes. Actually, I now see something similar with comp.lang.ml
> accessed via NNTP (additionally to the spam folder accessed over imap).
Discrepancies in NNTP groups are to be expected. NNTP just reports
high/low article numbers, and spam removal bots may remove articles. So
Gnus may believe that there are 20 new articles in the group, but upon
entering the group, half may already be gone.
There's nothing much nntp.el can do about that.
--
(domestic pets only, the antidote for overdose, milk.)
http://lars.ingebrigtsen.no * Lars Magne Ingebrigtsen
^ permalink raw reply [flat|nested] 28+ messages in thread
* bug#9243: 24.0.50; Gnus keeps seeing 101 unread spam
2012-09-05 18:07 ` Lars Ingebrigtsen
@ 2012-09-05 19:12 ` Stefan Monnier
2012-09-05 19:19 ` Lars Ingebrigtsen
0 siblings, 1 reply; 28+ messages in thread
From: Stefan Monnier @ 2012-09-05 19:12 UTC (permalink / raw)
To: Lars Ingebrigtsen; +Cc: 9243
> Discrepancies in NNTP groups are to be expected. NNTP just reports
> high/low article numbers, and spam removal bots may remove articles. So
> Gnus may believe that there are 20 new articles in the group, but upon
> entering the group, half may already be gone.
I know that. But what I'm describing is different:
- `g' tells me N unread articles
- then RET enters the group to discover there aren't any unread article
- so I exit and hit `g' again
- at which point Gnus tells me again that there are N (same N as before)
unread articles.
Stefan
^ permalink raw reply [flat|nested] 28+ messages in thread
* bug#9243: 24.0.50; Gnus keeps seeing 101 unread spam
2012-09-05 19:12 ` Stefan Monnier
@ 2012-09-05 19:19 ` Lars Ingebrigtsen
2014-01-30 23:04 ` Lars Ingebrigtsen
0 siblings, 1 reply; 28+ messages in thread
From: Lars Ingebrigtsen @ 2012-09-05 19:19 UTC (permalink / raw)
To: Stefan Monnier; +Cc: 9243
Stefan Monnier <monnier@iro.umontreal.ca> writes:
> I know that. But what I'm describing is different:
> - `g' tells me N unread articles
> - then RET enters the group to discover there aren't any unread article
> - so I exit and hit `g' again
> - at which point Gnus tells me again that there are N (same N as before)
> unread articles.
Aha. Hm.
One thing that I think may have that effect is if the Agent is really
wonky, for some reason or other.
When this happens next time, can you have a peek in
~/News/agent/nntp/<server>/agent.lib/active
and see whether the data for the group in question looks reasonable?
I'm just guessing, though...
--
(domestic pets only, the antidote for overdose, milk.)
http://lars.ingebrigtsen.no * Lars Magne Ingebrigtsen
^ permalink raw reply [flat|nested] 28+ messages in thread
* bug#9243: 24.0.50; Gnus keeps seeing 101 unread spam
2012-09-05 19:19 ` Lars Ingebrigtsen
@ 2014-01-30 23:04 ` Lars Ingebrigtsen
2014-01-31 13:58 ` Stefan Monnier
0 siblings, 1 reply; 28+ messages in thread
From: Lars Ingebrigtsen @ 2014-01-30 23:04 UTC (permalink / raw)
To: Stefan Monnier; +Cc: 9243
Lars Ingebrigtsen <larsi@gnus.org> writes:
> Stefan Monnier <monnier@iro.umontreal.ca> writes:
>
>> I know that. But what I'm describing is different:
>> - `g' tells me N unread articles
>> - then RET enters the group to discover there aren't any unread article
>> - so I exit and hit `g' again
>> - at which point Gnus tells me again that there are N (same N as before)
>> unread articles.
>
> Aha. Hm.
>
> One thing that I think may have that effect is if the Agent is really
> wonky, for some reason or other.
>
> When this happens next time, can you have a peek in
>
> ~/News/agent/nntp/<server>/agent.lib/active
>
> and see whether the data for the group in question looks reasonable?
>
> I'm just guessing, though...
Has this problem resolved itself, or are you still seeing it?
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog http://lars.ingebrigtsen.no/
^ permalink raw reply [flat|nested] 28+ messages in thread
* bug#9243: 24.0.50; Gnus keeps seeing 101 unread spam
2014-01-30 23:04 ` Lars Ingebrigtsen
@ 2014-01-31 13:58 ` Stefan Monnier
0 siblings, 0 replies; 28+ messages in thread
From: Stefan Monnier @ 2014-01-31 13:58 UTC (permalink / raw)
To: Lars Ingebrigtsen; +Cc: 9243-done
> Has this problem resolved itself, or are you still seeing it?
Hmm... I've stopped looking at that folder, to be honest.
Let's close it for now,
Stefan
^ permalink raw reply [flat|nested] 28+ messages in thread
end of thread, other threads:[~2014-01-31 13:58 UTC | newest]
Thread overview: 28+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2011-08-04 20:39 bug#9243: 24.0.50; Gnus keeps seeing 101 unread spam Stefan Monnier
2011-08-21 20:35 ` Lars Magne Ingebrigtsen
2011-08-22 22:30 ` Stefan Monnier
2011-09-10 18:58 ` Lars Magne Ingebrigtsen
2011-09-13 17:42 ` Stefan Monnier
2011-09-17 5:25 ` Lars Magne Ingebrigtsen
2011-09-17 21:07 ` Stefan Monnier
2011-09-18 7:27 ` Lars Magne Ingebrigtsen
2011-09-18 13:48 ` Stefan Monnier
2011-09-21 18:53 ` Lars Magne Ingebrigtsen
2012-01-06 23:38 ` Lars Magne Ingebrigtsen
2012-01-07 1:05 ` Stefan Monnier
2012-01-07 1:39 ` Lars Magne Ingebrigtsen
2012-01-07 2:45 ` Stefan Monnier
2012-01-07 3:25 ` Lars Magne Ingebrigtsen
2012-01-07 3:30 ` Lars Magne Ingebrigtsen
2012-01-07 3:31 ` Lars Magne Ingebrigtsen
2012-01-07 3:44 ` Lars Magne Ingebrigtsen
2012-01-10 19:56 ` Stefan Monnier
2012-01-25 23:35 ` Lars Ingebrigtsen
2012-04-10 21:18 ` Lars Magne Ingebrigtsen
2012-04-10 21:19 ` Lars Magne Ingebrigtsen
2012-04-11 0:56 ` Stefan Monnier
2012-09-05 18:07 ` Lars Ingebrigtsen
2012-09-05 19:12 ` Stefan Monnier
2012-09-05 19:19 ` Lars Ingebrigtsen
2014-01-30 23:04 ` Lars Ingebrigtsen
2014-01-31 13:58 ` Stefan Monnier
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).