Understood. This may do the trick, but it is a bit risky, as you mention
with UIDs. The behavior I'm seeing has to do with IMAP clients
(particularly Pine). By default, Pine displays messages in a folder in
the order in which they are presented by the IMAP server. You can always,
of course, sort by date. That works fine, except for messages sent by
users whose clocks are set to 2024, for example. Anyway, sorting a folder
with 15,000 messages in it isn't too bad either, but it is very handy to
let the messages appear as they arrive (default in Pine, "sort by
arrival")--very fast on both sides of the connection. The problem is that
I've transferred a bunch of mail into my maildirs. Had I always used IMAP
and left things on the server for the last 5 years, I'd be fine. But,
trying to combine things for my new repository (which is working GREAT,
for the most part) has messed all that up. I'm basically trying to
programmatically "reset" things such that it is the same as if I'd always
been storing my mail this way. And, as a post that just came in notes, it
does appear that Courier IMAP presents messages in the same order that the
filenames of the messages themselves sort (which is quite logical and
certainly corresponds to their order of arrival, regardless of date
headers). Going forward, everything is perfect as my messages arrive. I
am just trying to bring all of the past (transferred) stuff into the
scenario.
Thanks very much, again.
Oooohhhhh!! I seeee!
You're not saying that Pine is getting a "bad" or "alternative" set of date information at all (which I thought you were implying previously), but simply that it's not looking by default at the date information it *is* receiving. -- Ah-hah!
Now, it makes more sense to me. It's simply ignoring all the date information in favor of the server->client indexed list order -- not the arrival time at the server (i.e. delivery time) which I thought you meant.
But unfortunately, if I'm correct here... then parsing for the Received header, converting to a time() value, and replacing the time stamp in the file name won't actually even help in that case. -- Because, while I'm not even 75% sure (haven't looked inside Courier's code nor extensively tested)... I don't think that Courier even does name-based sorting.
Maybe Sam can speak up to correct me if I'm wrong, but it seems to me that Courier returns files in the order they were added to the directory. I.e. it simply open()'s the directory and reads linearly from what's returned. -- Or possibly it merely pulls them from the courierimapuiddb file linearly, but I don't think it does that even, 'cause I tried rearranging it, and they kept their index numbers the next time I logged in.
Anyway... I do believe that's the way Courier transfers them to the client... in directory order, not name-sorted order, nor date-sorted order.
(It appears name-based because it *should* be the same for any files added through the usual manner, where the name would reflect the time the file was created. But I don't think it actually is name-based.)
So, I *think* that even renaming the files isn't going to help you. I think you'd have to actually unlink all the files in the folder and then relink the files to the folder *in the order you want them* before it'll work the way you desire.
(Or at least unlink all files that should come *after* the one you want to "correctly" place earliest in the new listing order.)
That's a bit of work I think. But to do it you could make a tmp folder (or use the Maildir's tmp perhaps?? I assume that'd safe, Sam. Yes/no?) to add a hard link to the files, store any of the associations you want to each one somehow, manipulate them how you like, and add links back to the cur folder of the Maildir (and unlink the tmp files of course) in the determined order. -- If I'm right, you don't even have to actually change the names (which would mess up the UID associations), but can just relink the old name back in.
At least unlinking/linking rather than using cp/rm should make preserving the INTERNALDATE time stamps easier, since you don't have to record them all and then reset them when you're done mucking around with everything.
Sam, really... confirm or deny what I've said here, please. I really haven't looked at Courier's code for this. But merely did a quick test with files named 'zzz' (added first) and 'aaa' (added second) which seemed to appear in that order (zzz's index = 15 and aaa's index = 16) -- no matter how I later fiddled with their time stamps or their courierimapuiddb entries. And from there made a best guess at what would cause the observed behavior. ... But I rather doubt mine is the only explanation that could give the same results.
Anyone (esp. Sam) have anything more enlightened to say?
-jab
------------------------------------------------------- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01 _______________________________________________ courier-users mailing list [EMAIL PROTECTED] Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users
