Date order received is Borked. It is the offset into the mail store and was never as described. Following changed to the issuing of ID numbers, in the compact process it is now meaningless.

The order will however be the order of the mail in the store I think. But I have never actually seen it documented.

Hi Matt,

Thanks for the response. You may see in my later question, that I found that the 'received order' numbers begin anew, if copied into a new IMAP folder. That makes sense if the IMAP folders are all treated as separate mailboxes, which I assume is the case.

I'm was bit confused as to why the numbers don't begin again in a new Local Folder, but, I suppose these must keep the number they received in the Inbox--which under POP would have applied to the whole client--until they are 'sent' (copied) to one of the 'live' folders.

You seem to be saying that the 'received order' would be reset on compacting, but it stays the same except when copying to a new IMAP folder?

Things have probably been confused by virgin switching from POP3 to IMAP and me starting to mix old and new together in the same year folder.

I also thought, at first, that files were uploading in the folder order, and it did seem to work, but it turned out that this was just luck, as consecutive dates do get moved apart some of the time.

Puzzling, but still quite interesting.

Cheers (y)

Back to your earlier question…

If you have ever selected a block of files and started a copy or move, you may have noticed that they are usually not processed in any obviously predictable order. There is something odd about the way such a block is collated and marshalled. I don't know if this applicable to email, but it makes the point that computers don't always do the obvious thing.

Putting that aside, in email we are allowed to make multiple connections to an IMAP server, and in this multithreaded type of scenario, the order of delivery is non-deterministic. Small items lower down in the queue may overtake a larger item.

Thanks Zenos,

I ended up using two windows side by side and following the uploads in different amounts at a time. Probably a lot depends on the upload and download speeds of the connection. I'm on twisted wire, and, I suspect things would be better on faster cable. Anyhow: in a fresh IMAP folder, it does start numbering in sequence, and it does upload in date order. That is, until it gets to a file over 4Meg, at which point it will often time out and try reconnecting to server.

Once it times out, the synchro starts to 'download' the stuff that you thought you just put in the folder, and it's best to wait for that to stop before putting any more in.

I can copy local folder to local folder instantly, but copying to IMAP it starts to play up at around the 400 mark. After that it copies a few, misses a few, more, copies one, misses a load... Downloading is better, and you can almost get away with twice the number at a time, so long as there are no big files.

Once I learned to take it steadily, I got all the mail filed at last. I haven't seen a great deal of logic in the big numbers on the local folders, but, with all the daily downloads and deletions, I guess it's bound to get into a mess.

Still puzzled as to why Remove Duplicates works more thoroughly on the IMAP folders than the local folders. I notice that files get 200 bytes bigger when moved to a local folder, but they don't get smaller when moved back, so RD isn't using that (I don't run it to compare exact size or line number anyway.). Still: It was good to be able to use the IMAP folders as a filter, and then load the trimmed down folder back to local.

So now there's just the curious add on behaviour of my other question to sort out...

And my touch pad pointer has suddenly decided to start behaving as if it's tied on elastic to the top right corner of the screen. Looks like I may have worn it out! There's always something!  :)

Thanks for the suggestions all.

(y) (y)