>>>> It seems that IMAP has the concept of a "message sequence number", >>>> which is a number from 1 to the number of messages in a folder; that >>>> might be the right thing to use. > >no. MH message numbers can have holes and can be reassigned. IMAP is >always 1..N, no holes.
I was thinking that if we want to have something that IMAP already uses to refer to messages that is close to how message numbers work today in exmh, then that would be useful. But you say below that you want something more permament than how message numbers work today in IMAP. Alright, moving on ... >Maildir/.Archives.2011/cur/1321741485.M572952P74802.ss.vix.com,S=1369,W=1407:2,FR > >i'm not sure exactly what all that crap is or means, "1321741485" looks >like a seconds-since-1970, and "M572952P74802" looks a little like >device+inode. i don't know how Dovecot gets from that file name to an >IMAP UID and i don't know if it does so in a Dovecot specific way or >whether this is a Maildir thing (Dovecot-independent). I can fill some of this in. "Most of the crap" is something just guaranteed to be unique. Hence the timestamp+device+inode+hostname stuff. S=1369 is the size of the file in bytes (to avoid a stat()), W=1407 is the size of the file in CRLF format. Those are Dovecot-specific extensions. Everything after the : are file flags defined by Maildir (2 being the verison number, F means "user defined flag", R means message has been read). Now, as for how Dovecot converts that to a IMAP UID ... does there happen to be a file called "dovecot-uidlist" somewhere? From what I see that's how the mapping from IMAP UID to filename happens. >the reason i'm thinking that we'll have a .dir/.pag file per folder is >to make sure that MH message number "X" remains more stable than an IMAP >message number would be, but less stable than an IMAP UID would be. we'd >generate this "db" the first time we visit a folder, we'd regenerate it >if the directory mtime was more recent than the "db" mtime, and we'd >update this db whenever we ran "inc", "refile", "pack", "rmm" or >"sortm", and we'd access this db whenever we ran "show" or "inc" or >"repl" or similar. I see that Dovecot seems to use a simple text file; maybe that's good enough for a first-level effort? Or perhaps because it's longer running it's not as much of a performance drag. --Ken _______________________________________________ Nmh-workers mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/nmh-workers
