I thought that there was a function that counted the final size of a message automatically... but I guess not! In any event, I see that at the very end of store_message_temp(), there's an update:
db_update_message(msgidnr, unique_id, totalmem+headersize, 0); The first problem is that the fourth argument, rfc_size, is 0. How does the RFC size differ from the Message size? The second problem seems to be that totalmem+headersize is not yielding a correct result. They are of nominally different types, size_t and u64_t, but that should work, no? Aaron Ilja Booij <[EMAIL PROTECTED]> said: > Found the problem. Using the new delivery chain, the size of a message > is never stored, so the total size of the message (as stored in the > messagesize field in the physmessage table) is only the size of the header. > > Aaron, could you take a look at this? I guess the total size of the > message needs to be stored somewhere in the store_message_temp() function. > > I'll be off now, and won't be back until Monday. I want to release RC3 > then. I hope we can tackle the Mozilla problem from then on (unless > anybody happens to find the cause of the problem before Monday :) ). > > Ilja > > > Ilja Booij wrote: > > > Hi, > > > > it seems that calculation of a user's mailbox size isn't working > > properly (not all messageblks are counted). > > > > I'm working on this :) > > > > Ilja > > _______________________________________________ > > Dbmail-dev mailing list > > Dbmail-dev@dbmail.org > > http://twister.fastxs.net/mailman/listinfo/dbmail-dev > _______________________________________________ > Dbmail-dev mailing list > Dbmail-dev@dbmail.org > http://twister.fastxs.net/mailman/listinfo/dbmail-dev > --
