Re: msgmap serial number regeneration [was: Q: V2 format]

[ebiederm@xmission.com (Eric W. Biederman)]

Eric Wong <e@80x24.org> writes:

> "Eric W. Biederman" <ebiederm@xmission.com> wrote:
>> I believe we can modify the msg number assignment to assign numbers to
>> deletes as well as adds.   Short of the same Message-ID coming up twice
>> that should be enough for the current backwards loop to assign message
>> ids reliably.  And even Message-IDs comming up twice is handle-able.
>
> OK, I would likely accept a patch to fix that.
>
> A note about Message-ID uniqueness...  The v2 code will generate
> a new, truly unique Message-ID on duplicates and use that in
> msgmap instead what was in the message.  It's gross, but I needed
> to do that to allow all messages to be accessible via Message-ID
> over NNTP, because:
>
> a) some legit messages reuse Message-IDs :<
>
> b) some broken mailers (including some versions of git-send-email)
>    put multiple Message-IDs in the same message, so the code
>    needs to handle messages with any number of Message-IDs
>    anyways.

I will send the patch along shortly.

I mispoke when I said the problem could be fixed by assigning numbers to
deletes.  The actual problem was that not every add was assigned a
number.  So the fix simpler than I expected.

It is interesting to note that
INSERT
DEL
INSERT

In sqlite does not reuse numbers in the primary key.    So not
reassigning numbers is what the local sqlite data base does as well.

I need to track down what the v1 bug with add-remove-add was.  I think
the way I have updated the code I won't need the bug fix for v1.  But I
haven't checked that scenario yet.

I also need to write a test case sigh.

But in practice I have this working for git mailling list archive.


Eric