On Wed, 5 Mar 2003, Charlie Brady wrote: >On Wed, 5 Mar 2003, Andreas Aardal Hanssen wrote: >> Is also says that UIDVALIDITY must stay as is or _increase_ for one >> mailbox even if the mailbox is deleted and then recreated later on. Some >> servers reset UIDVALIDITY when a mailbox is deleted. Those servers are >> incompliant with the protocol. >That depends on how you define "reset". If "reset" means "set to zero", >then yes. True, that was unclear. With "reset" I meant "set to zero" or in general "set to something lower than what it was". :) >> Today, UIDVALIDITY is delegated through a time(NULL) call, but it should >> just be set to 1, then 2, then 3 etc.. In order to guarantee that a >> mailbox always receives a higher UIDVALIDITY than what it had before, the >> bincimap-<mailbox>-uidvalidity file must be left as "unused" metadata in >> the root Maildir. >The last time I checked, time was still monotonically increasing. How does >"time(NULL)" not guarantee that a UIDVALIDITY of a recreated mailbox is >greater than UIDVALIDITY of the previous incarnation of the mailbox?
If you have two clients, one deletes a mailbox with 5 messages and another client creates it again within one second. New messages in a this mailbox will get the same uidvalidity/uid values as the messages in the first folder. I guess time(NULL) is the best we can provide if there is no info on former uidvalidity values, but if we know the former value we should add 1 to it rather than use time(NULL). Or we could wait one second here too :-/. >(Probably a related question) Why can't uidvalidity files be kept inside >the maildir? (guess you mean submailbox/maildir) Because then they'll be deleted when the mailbox is deleted.. Andy -- Andreas Aardal Hanssen | http://www.andreas.hanssen.name/gpg Author of Binc IMAP | Nil desperandum
