From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.user/17913 Path: news.gmane.org!not-for-mail From: Eric Abrahamsen Newsgroups: gmane.emacs.gnus.user Subject: Re: is this a bug in gnus v5.13? Re: gnus INBOX housekeeping, kept (copies of) mail lying around Date: Sat, 09 Jan 2016 12:02:04 +0800 Message-ID: <87wprj5rk3.fsf@ericabrahamsen.net> References: <87r3hw70ee.fsf@hillenius.net> <878u446w17.fsf@hillenius.net> <874mes6uou.fsf@hillenius.net> <87mvsk5cxu.fsf@hillenius.net> <87egdw5bgj.fsf@hillenius.net> <87mvshdf2o.fsf@hillenius.net> <87h9ipbvkk.fsf@hillenius.net> <874meo8q1a.fsf@hillenius.net> <87poxc5n23.fsf@hillenius.net> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1452312158 31169 80.91.229.3 (9 Jan 2016 04:02:38 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 9 Jan 2016 04:02:38 +0000 (UTC) To: info-gnus-english@gnu.org Original-X-From: info-gnus-english-bounces+gegu-info-gnus-english=m.gmane.org@gnu.org Sat Jan 09 05:02:25 2016 Return-path: Envelope-to: gegu-info-gnus-english@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1aHkjR-0004m7-4j for gegu-info-gnus-english@m.gmane.org; Sat, 09 Jan 2016 05:02:25 +0100 Original-Received: from localhost ([::1]:38905 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aHkjQ-0002kM-8M for gegu-info-gnus-english@m.gmane.org; Fri, 08 Jan 2016 23:02:24 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:55536) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aHkjN-0002k4-13 for info-gnus-english@gnu.org; Fri, 08 Jan 2016 23:02:22 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aHkjI-0002n0-Up for info-gnus-english@gnu.org; Fri, 08 Jan 2016 23:02:20 -0500 Original-Received: from plane.gmane.org ([80.91.229.3]:48912) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aHkjI-0002lL-L9 for info-gnus-english@gnu.org; Fri, 08 Jan 2016 23:02:16 -0500 Original-Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1aHkjG-0004dJ-73 for info-gnus-english@gnu.org; Sat, 09 Jan 2016 05:02:14 +0100 Original-Received: from 111.197.159.241 ([111.197.159.241]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 09 Jan 2016 05:02:14 +0100 Original-Received: from eric by 111.197.159.241 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 09 Jan 2016 05:02:14 +0100 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 112 Original-X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: 111.197.159.241 User-Agent: Gnus/5.130014 (Ma Gnus v0.14) Emacs/25.1.50 (gnu/linux) Cancel-Lock: sha1:dSx8ZB0Y+XjhUxcqPHpm2zccNog= X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 80.91.229.3 X-BeenThere: info-gnus-english@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Announcements and discussions for GNUS, the GNU Emacs Usenet newsreader \(in English\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: info-gnus-english-bounces+gegu-info-gnus-english=m.gmane.org@gnu.org Original-Sender: info-gnus-english-bounces+gegu-info-gnus-english=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.gnus.user:17913 Archived-At: Gijs Hillenius writes: > On 8 Jan 2016, Eric Abrahamsen wrote: > >> Gijs Hillenius writes: >> >>> On 7 Jan 2016, Eric Abrahamsen wrote: >>> >>>> Gijs Hillenius writes: >>>> >>>>> [...] hope snipping this much is ok.. >>>>> >>>>>>> >>>>>>> If my Gnus (5.13, part of Debian's Emacs) copies messages back >>>>>>> into the INBOX, does fancy-split set the delete/expunge IMAP flag >>>>>>> to these? >>>>>>> >>>>>>> Because, if it does not flag them for deletion, would that >>>>>>> perhaps explain why the nightly Cyrus pruning does not do >>>>>>> anything? Cyrus is set to remove from disk all messages that have >>>>>>> been flagged for deletion for 3 days. >>>>>> >>>>>> No, no flags are set. From IMAP's point of view, splitting is >>>>>> simply a MOVE operation. Sorry, I misspoke earlier when I said the >>>>>> messages were *copied* back into the same group. They're actually >>>>>> MOVEd. That means there's only ever one copy of the message, but >>>>>> it gets a new UUID number each time. >>>>>> >>>>>> No new flags are set at all. >>>>> >>>>> So, these message come back int the INBOX, but are not shown >>>>> anymore by Gnus. They are also not marked as deletable and that >>>>> would explain why Cyrus does not remove them from disk, yes? >>>> >>>> Right. Once they are given the Seen flag, that flag sticks with them >>>> even if they are moved around (including "moved" into the same group >>>> they were already in). That Seen flag means Gnus won't show them to >>>> you again. >>>> >>>> I think the distinction here is between message deletion, and adding >>>> the "Deleted" flag. Deletion occurs as part of the move process (the >>>> message is in one instant removed from one group and added to >>>> another). If you're MOVEing to the same group, the message is >>>> deleted from that group, then added back to that group. But it keeps >>>> its old flags, and no other flags are put on it (there's nothing in >>>> the splitting process that would add a Deleted flag), so Cyrus >>>> doesn't see any reason why it should garbage-collect the message at >>>> the end of the day. >>> >>> So, we're saying the same thing, correct? >>> >>> What I don't understand is - and apologies for being long-winded: >>> >>> The way I use Gnus: when I start it, or hit g, new messages in the >>> INBOX are fancy-splitted, and moved to various IMAP folders. So I see >>> several INBOX.subfolders with a new, unread messages. These copies, >>> that are kept in the INBOX, as a user I don't know about these, I >>> don't see them in any IMAP mail client. Is that why 'root' sees 8k >>> messages in the INBOX when root happens to look at this users' INBOX >>> folder? >>> >>> How can Cyrus tell these message can safely be trashed? I guess this >>> is a question for a Cryus mailing list, where it not that this >>> "keeping a copy" does not happen for mail that is split on the server >>> by a Sieve script. So, perhaps this is a Gnus fancy-split bug? >> >> Okay hang on, we're not quite talking about the same thing here. If >> messages are split into _other_ groups, then everything should go fine >> -- they should leave the INBOX altogether (what's your value for >> nnimap-inbox on this server?) go to the new group, and Gnus should >> never try to split them again. > > Aha! In my case, messages are copied rather than moved to the > INBOX.subfolder. So they end up in two folders: the INBOX (hidden, and > out of reach) and in the INBOX.subfolder. > > That will surely be an error on my part. But which one & where.. Okay, you did describe what was happening earlier in the thread, I just got distracted. Sorry! So you mentioned your fancy split methods look something like this: (setq nnimap-split-fancy '(| ("From" "googlealerts.*" "INBOX.google-alerts") (any "c[...]" "INBOX.tmp") ;; Invoke the BBDB (: (lambda () (car (bbdb/gnus-split-method)))) ;; Default mailbox ("INBOX" ""))) I'm not a splitting expert (I've stopped using it, and wasn't very good at it to begin with), but there are a couple of things odd about this. First, I don't think that's how you're supposed to use `bbdb/gnus-split-method'. The comments in bbdb-gnus indicate that you're supposed to do something like this: (setq nnmail-split-methods 'bbdb/gnus-split-method) (setq bbdb/gnus-split-nomatch-function nnimap-split-fancy) Ie, the bbdb gets a chance to return a split first, and only if it doesn't come up with anything does nnimap-split-fancy come into play. So you'd set something like the above in your init, and then remove the lambda from your fancy splits. Second, ("INBOX" "") looks weird to me. The splitting examples I've seen all just end in a plain box name: "INBOX". Maybe try making those changes, and see if it improves? Eric