On Mon, 2003-01-20 at 09:24, Andreas Aardal Hanssen wrote: > So what you're saying is that cacheing the time(NULL) value and keeping it > in one single-point-of-failure file will solve the problem? How is this > different from calling time(NULL)?
time(NULL) doesn't guarantee unique UIDVALIDITY if more than one mailbox was created within one second. That is the only real problem that I see with RENAME. > I never claimed that using time(NULL) will solve the RENAME problem. And that is the only thing I'd like to fix. Using timestamps or whatever ascending value with CREATE has no problems, I was never talking about that. > This thread started with me asking wether or not there is _any_ compliant > way of solving the RENAME problem. I see two, neither which are too tempting: a) change the UIDVALIDITY every time b) keep permanently track of the last UIDVALIDITY for each deleted folder, use MAX(renamed_uidvalidity, last_uidvalidity+1) If we just agreed that the UIDVALIDITY doesn't _really_ have to be ascending, at least with RENAME, neither would be necessary if server used unique UIDVALIDITY for each folder. At least with the above servers would have some somewhat reasonable way to deal with this, other than just always changing the UIDVALIDITY. The current behaviour is the worst of all, it breaks all clients if the RENAMEd mailboxes were created at the same time. > If the client does the "!=" test instead of the ">=" test, then it's a > client that allows more than the RFC allows. I'm not quite sure of the > implications of this, but I can not imagine why a client would use "!=" > instead of ">=". I can't imagine why client would use ">=" instead of "!=". Change is a change, no matter the direction. Besides, the rfc2060 mentions "growing" UIDVALIDITY twice, "different" UIDVALIDITY 4 times.
