The recent suggestions about adding the ability to keep the Exim
queue in more than one directory reminded me of an infelicity in
the existing implementation. While refamiliarising myself with that
I have discovered what seems to be a bug: at any rate, if it isn't
a bug it is a very weird spec!
"exim -bp" displays the queue in `natural' order, i.e. that returned
by queue_get_spool_list(FALSE). This is just the readdir() order of
the -H files. Except for the occasional Unix flavour in which readdir()
always returns names sorted, this will not be sorted msgid order. The
latter is essentially time-on-queue order, and is probably what the
naive mail manager would think of as `natural'.
The {bug|weird-spec} arises when "exim -q msgid1 msgid2" is executed.
This processes the queue in -bp order, skipping any messages with
msgid < msgid1, but *stopping* as soon as it sees one with msgid > msgid2.
Because the order is not lexicographical, this can cause some messages
with msgid1 <= msgid <= msgid2 not to be looked at. For example, if
msgid1 = msgid2 and is the msgid of a message on the queue, that message
may or may not be processed, depending on whether there are larger (later)
msgids earlier in the `natural' order.
Wouldn't it be better if queue_get_spool_list(FALSE) returned the list
sorted lexicographically? And, for that matter, if queue_get_spool_list(TRUE)
returned a truely (pseudo-)randomised order rather than the poor-man's-method
used in the current code? List sorts aren't really that hard to code or
expensive to execute!
Chris Thompson Cambridge University Computing Service,
Email: cet1@??? New Museums Site, Cambridge CB2 3QG,
Phone: +44 1223 334715 United Kingdom.
