Re: Issue with nnml backend and gnus-group-get-new-news()

[Francis Moreau <francis.moro@gmail.com>]

Hello Tassilo,

On Tue, Dec 1, 2009 at 9:17 PM, Tassilo Horn <tassilo@member.fsf.org> wrote:
> Francis Moreau <francis.moro@gmail.com> writes:
>
> Hi Francis!
>
>>> Hm, what does M-x nnmail-split-history RET say?
>>
>> So I tried different values for the prefix and here are the ouptut of
>> M-x nnmail-split-history for each values. For each values, a mail was
>> previously sent and should reach my 'Inbox' group.
>>
>> 'g'    Ok -> Inbox:2599
>> '1 g' Ok -> Inbox:2600
>>
>> '2 g' Ko -> Inbox:17
>> '3 g' Ko -> Inbox:18
>> '4 g' Ko -> Inbox:19
>> '5 g' Ko -> Inbox:20
>>
>> 'g'    Ok -> Inbox:2601
>>
>> Ok means that the mail finally was delivered to the right group
>> ('Inbox'), otherwise Ko, the mail is stuck in the 'Incoming' stage.
>>
>> As you can see the sequence number after "Inbox::" seems to have been
>> reset in the non working case.
>
> Oh, that's interesting.
>
> Please enter your Inbox and do `j 17', ..., `j 20', and check if those
> messages are indeed the new ones, which are also there as Incoming
> files.

Ok doing 'j 17, j 18..., j20' always gives the same result:

   Couldn't go to article 17
   Couldn't go to article 18
   ...
   Couldn't go to article 20

> If that's indeed the case, then it seems possible that old mails
> are overwritten, which would be an extremely serious bug.  Another
> possibility would be that in that case Gnus reuses article numbers of
> already deleted messages, and the fetching somehow assumes that they
> always increase, and so the new ones with old article numbers aren't
> recognized as being new.
>
> In any case, please write a bug report (M-x gnus-bug) with a very
> detailed description.  The trace analysis you did above is good.
>

Ok I'll do that.

Thanks !
-- 
Francis