* 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).