Re: is this a bug in gnus v5.13? Re: gnus INBOX housekeeping, kept (copies of) mail lying around

[Gijs Hillenius <gijs@hillenius.net>]

On  8 Jan 2016, Eric Abrahamsen wrote:

> Gijs Hillenius <gijs@hillenius.net> writes:
>
>> On  7 Jan 2016, Eric Abrahamsen wrote:
>>
>>> Gijs Hillenius <gijs@hillenius.net> 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..

> The situation I was talking about was when messages _aren't_ matched
> by any split methods, and they stay in the INBOX. In that case, they
> keep getting removed and copied back into the INBOX.

ok, I get this. These messages will always be visible in the mail
client. These messages are not what I'm trying to explain :-)

> If your messages are getting split into other groups, then things
> should work as expected. Remind of the problem again?
>
> Sorry about the confusion...

That is me, probably