On Tue, 2003-01-28 at 02:24, Cyrus Daboo wrote: > The only caveat is for servers that do not use timestamps for UIDVALIDITY. > In that case those servers would have to ensure that the new UIDVALIDITY is > greater than any UIDVALIDITY for mailboxes that may have previously existed > with any of the new names.
They have to ensure it already with CREATE, so I don't think it's really relevant to RENAME problems. A bit more thinking: RENAME has to be atomic, but I don't think the UIDVALIDITY updating needs to be (I can't think of any cases it could break). If they're first updated, and only then the actual mailbox name is changed, the whole mailbox hiearchy wouldn't need to be locked. Well, actually there's still a small problem if it was done with timestamps. If mailboxes were swapped exactly at the same time, their UIDVALIDITY would be same and there's a small possibility of another client accessing mailbox A after it's UIDVALIDITY was updated, but before it was renamed to B (and C to A). Using "time(NULL) + uidval_counter++" would prevent that pretty well though.
