Thanks much! I should have noticed that I changed that from %llu to %d, but... It seems to work fine with just casting virtual_messagestatus to int, also.
Jesse ---- Original Message ---- From: Roel Rozendaal - IC&S <dbmail-dev@dbmail.org> To: dbmail-dev@dbmail.org Subject: Re: [Dbmail-dev] C coding problem Sent: Mon, 23 Jun 2003 19:50:22 +0200 > Hi jesse, > > the problem probably is that you use '%d' (int) type argument for > virtual_messagestatus whereas the virtual_messagestatus is actually > declared as an u64_t - you should use '%llu' (check dbmailtypes.h). I > admit that using a 64-bit number is totally way out of order for this > status attribute but that's another issue ;-) > > regards roel > > > Jesse Norell heeft op maandag, 23 jun 2003 om 17:29 (Europe/Amsterdam) > het volgende geschreven: > > > > > Hello, > > > > Ok, I'm working on changing everything to #defines for status > > value, and as the local college doesn't offer "Stupid C coders 101," > > can anyone tell me why this (from db_update_pop(), and don't think > > correctness of the query, I'm just trying to get snprintf to work): > > > > snprintf (query,DEF_QUERYSIZE, > > "UPDATE messages set status=%d WHERE message_idnr=%llu AND > > status<%d", > > ((struct message *)tmpelement->data)->virtual_messagestatus, > > ((struct message *)tmpelement->data)->realmessageid, > > STATUS_DELETE > > ); > > > > Creates the following query: > > > > [UPDATE messages set status=1 WHERE message_idnr=398383986507776 AND > > status<0] > > > > > > Whild this, in the exact same place, for the exact same > > user/message# in pop3: > > > > snprintf (query,DEF_QUERYSIZE, > > "UPDATE messages set status=%d WHERE message_idnr=%llu AND > > status>%d", > > STATUS_DELETE, > > ((struct message *)tmpelement->data)->realmessageid, > > ((struct message *)tmpelement->data)->virtual_messagestatus > > ); > > > > Creates this query: > > [UPDATE messages set status=2 WHERE message_idnr=92756 AND status>1] > > > > In the second query, all format args are read correctly - in the > > first query, virtual_messagestatus is (ie. it is 1), but realmessageid > > is wrong and the last arg is alway read as a 0, no matter what it is > > (hard coded number, variable, or #define). This is in dbmysql.c, on > > a debian stable box. > > > > Thanks, > > Jesse > > > > > > > > ---- Original Message ---- > > From: Aaron Stone <dbmail-dev@dbmail.org> > > To: dbmail-dev@dbmail.org > > Subject: RE: [Dbmail-dev] message status 4 > > Sent: Wed, 18 Jun 2003 12:27:45 -0700 (PDT) > > > > Actually, if you take a look at my lmtp/sorting patch, I split off a > > couple of these shared functions into smaller files, including > > create_unique_id(). I hope that Roel can review and comment on that > > patch > > soon (hint hint ;-) because I think it sets the code in the right > > direction for enhancing the delivery pipeline. > > > > You do seem to be correct that the status field isn't being used > > consistently, and what's worse, there are "magic numbers" scattered > > throughout the code. These should all be changed to defined values, > > such as... > > > > #define STATUS_ACTIVE 0 > > #define STATUS_INSERT 5 > > #define STATUS_DELETE 2 > > #define STATUS_EXPUNGE 3 > > > > Aaron > > > > > > On Wed, 18 Jun 2003, Jesse Norell wrote: > > > >> > >> Hello, > >> > >> Back to work, after a few days recovering from a > >> little trencher incident... > >> > >> As for the idea presented here, using a status id for > >> "not yet complete" messages - the pop3 server does this > >> already, using status 5, but imap does not - it instead > >> uses an empty unique_id (ie. '') to handle the same thing, > >> from what I've seen. I don't see any problems (eg. pop3 > >> session disreguards messages with unique_id=''), but it > >> would be a bit more efficient and less confusing to be > >> consistent in what a partially inserted message looks like. > >> > >> I plan on making a small util.c with a create_unique_id > >> function, as it needs to be included in more than just > >> dbmail-smtp. Seems overkill to have a dedicated file, and > >> there's no such "misc. utility functions" file yet, so... > >> > >> > >> > >> ---- Original Message ---- > >> From: Jesse Norell <dbmail-dev@dbmail.org> > >> To: dbmail-dev@dbmail.org > >> Subject: [Dbmail-dev] message status 4 > >> Sent: Tue, 10 Jun 2003 09:07:06 -0600 (MDT) > >> > >>> > >>> Hello, > >>> > >>> In implimenting a unique_id fix, in several issues in the past, and > >>> in message insertion in general, it seems appropriate to have a > >>> message status that basically just means 'not yet > >>> processed/complete,' > >>> for which I propose using message status = 4 (which isn't used > >>> anywhere, right?). I believe all the existing code should handle > >>> that without change (ie. if status is 4, it won't show in any > >>> mailboxes, get cleaned by maintenance, etc.), so there should be no > >>> migration problems unless someone uses status 4 locally (which a > >>> trivial db update can fix). > >>> > >>> This would make things like the "message inserted, but not yet > >>> filtered" race condition Aaron was going to have to address a while > >>> back easy - just insert all messages with status = 4, do whatever > >>> processing, and update to 2 when the message is fully processed. > >>> It would fix a race condition in the current insertion code where a > >>> message actually changes unique_id and another where the messages > >>> table entry exists, but messageblk entries do not yet (ie. if > >>> messages entry was inserted, then a user checks POP3 before > >>> messageblk is inserted, it'll hang OE waiting for data, till a > >>> timeout period, then error). > >>> > >>> Sound good / any objections (particularly from IC&S)? > >>> > >>> Jesse > >>> > >>> > >>> -- > >>> Jesse Norell > >>> jesse (at) kci.net > >>> > >>> > >>> _______________________________________________ > >>> Dbmail-dev mailing list > >>> Dbmail-dev@dbmail.org > >>> http://twister.fastxs.net/mailman/listinfo/dbmail-dev > >>> > >> -- End Original Message -- > >> > >> > >> -- > >> Jesse Norell > >> jesse (at) kci.net > >> > >> > >> _______________________________________________ > >> 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 > > > > -- End Original Message -- > > > > > > -- > > Jesse Norell > > jesse (at) kci.net > > > > > > _______________________________________________ > > Dbmail-dev mailing list > > Dbmail-dev@dbmail.org > > http://twister.fastxs.net/mailman/listinfo/dbmail-dev > > > > _________________________ > R.A. Rozendaal > IC&S > T: +31 30 2322878 > F: +31 30 2322305 > www.ic-s.nl > > _______________________________________________ > Dbmail-dev mailing list > Dbmail-dev@dbmail.org > http://twister.fastxs.net/mailman/listinfo/dbmail-dev > -- End Original Message -- -- Jesse Norell jesse (at) kci.net
