I've tracked down the problem in the old mimeparser. Straight headache stuff. A
typical off-by-one error.
In fact this is so arcane I don't really understand it. Maybe Ilja or Roel can
shed some light on this. The patch that fixes the problem:
diff -u -r1.17 dbmsgbuf.c
--- dbmsgbuf.c 2004/09/15 13:08:27 1.17
+++ dbmsgbuf.c 2004/10/07 12:13:30
@@ -218,7 +218,7 @@
/* move buf to make msgbuf_idx 0 */
memmove(msgbuf_buf, &msgbuf_buf[msgbuf_idx],
(msgbuf_buflen - msgbuf_idx));
- if (msgbuf_idx > ((msgbuf_buflen + 1) - rowpos)) {
+ if (msgbuf_idx > (msgbuf_buflen - rowpos)) {
zeropos.block++;
zeropos.pos = (msgbuf_idx - ((msgbuf_buflen) - rowpos));
} else {
I'm guessing the +1 was added to compensate for bugs elsewhere sometime ago.
Some logentries that look possibly related:
revision 1.8
date: 2004/04/14 09:04:55; author: ilja; state: Exp; lines: +2 -1
msgbuf_buf is now initialized to hold '\0' on start.
revision 1.5
date: 2004/03/16 15:54:59; author: ilja; state: Exp; lines: +9 -2
No longer adds the '\r' on the end of every line. Now only adds it if
the line is ended with a single '\n' and not with '\r\n'
Aaron Stone wrote:
If it means that HEAD won't be useable for a day or two, I don't think
that you should worry about it. Better that more people are able to see
some of the GMime code and begin to understand it, even if it isn't 100%
ready.
Aaron
Paul J Stevens <[EMAIL PROTECTED]> said:
It's in the retrieval code. GMime does some reformatting in the
mimeheaders (un-wrapping of headers, and unquoting of attributes)
of the mimeparts which are apparently confusing the old mimeparser
used in the retrieval code.
If it's something minor in the current mimeparser, I'll fix it.
Otherwise, I'll back out the insertion code committed today, and
work on the retrieval code to use gmime as well first.
I wont be able to work on this until around 12:00 gmt tomorrow.
Paul J Stevens wrote:
Sorry guys,
Something is still amiss in the insertion code. I'm on it.
Paul J Stevens wrote:
Hi all,
As promised, I've committed the first gmime code fragments. They are
currently used for message insertion only.
* dbmail-message.c, dbmail-message.h: new files implement
DbmailMessage object and interfaces.
* Makefile.am: added dbmail-message.c to COMMON files list
* acinclude.m4, configure.in: added gmime support
* db.c, db.h, header.c, header.h, lmtp.c, main.c, pipe.c,
pipe.h: use new gmime code in dbmail-message.c for message
insertion.
Please test this code. It works for me, but I'm curious if this solves
Dan's problems with dbmail-smtp.
--
________________________________________________________________
Paul Stevens mailto:[EMAIL PROTECTED]
NET FACILITIES GROUP PGP: finger [EMAIL PROTECTED]
The Netherlands________________________________http://www.nfg.nl
_______________________________________________
Dbmail-dev mailing list
[email protected]
http://twister.fastxs.net/mailman/listinfo/dbmail-dev
--
________________________________________________________________
Paul Stevens [EMAIL PROTECTED]
NET FACILITIES GROUP GPG/PGP: 1024D/11F8CD31
The Netherlands_______________________________________www.nfg.nl
