----------------------------------------------------------------------
Eduardo Stern - 13-Mar-05 07:46 CET
----------------------------------------------------------------------
No. I'm using Apple Mail. I use DBMAIL with success on a RedHat 9 system.
It only occurs in SuSE, both 9.1 and Enterprise 9.
Is your server or client on amd64 perhaps?
The problem appears to be that DBMAIL is wrongly setting the maximum
values for a 64bit integer to 18446744073709551615, or (2^64-1).
so, if we do:
unsigned long long somevalue = 0;
somevalue--;
we get just that. I can see where this might be happening in _ic_fetch().
Where is dbmail getting this value from? The max value for a 64 bit
integer, in PostgreSQL, is 9223372036854775807, or (2^63-1). This is
caused somewhere by mixing the signed and unsigned long long integers.
I can guard against this condition, but that will only trigger an other error I
suspect.
I have no more log messages, this is the same message that's given to me
every time.
That can't be right. Are you using TRACE_LEVEL=5? I'm especially interested in
the COMMAND that leads up to this problem. If I had access to Apple Mail, I'd
also run an ethereal session to read the imap interaction from the wire. But a
level 5 trace should be sufficient.
I made a very stupid "fix" by adding this code to db.c, just before dbmail
defines the query with the BETWEEN:
if (msg_idnr_high>9223372036854775807)
msg_idnr_high=9223372036854775807;
I've located the bug alright, but I want to reproduce it first to make sure I
actually fix it.
--
________________________________________________________________
Paul Stevens mailto:[EMAIL PROTECTED]
NET FACILITIES GROUP PGP: finger [EMAIL PROTECTED]
The Netherlands________________________________http://www.nfg.nl
