On 20 Jan 2003, Timo Sirainen wrote: >Simple. Use a global or user-global UIDVALIDITY counter. How exactly >that is done is implementation problem. I was thinking of a .uidvalidity >file which contains it. It would initially begin with time(), but after >that it would grow one at a time. That way it wouldn't really matter if >the file itself had to be recreated, and it also wouldn't matter if >client created multiple mailboxes within one second.
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)? >CREATE a -> UIDVALIDITY == time() == eg. 1234 >CREATE b -> UIDVALIDITY == time() == eg. 1235 >.. use both mailboxes .. >DELETE b >RENAME a b >Now b's UIDVALIDITY is 1234, which is less than the previous 1235. >Meaning it's not conforming to the IMAP spec. Even worse if the >mailboxes were created at exactly the same time. Off the point. Unix time is recommended in general so that the server need not keep track of a history of uidvalidity values. So if a folder is deleted and then recreated later on, you can call time(NULL) to get a valid UIDVALIDITY. I never claimed that using time(NULL) will solve the RENAME problem. This thread started with me asking wether or not there is _any_ compliant way of solving the RENAME problem. >> The point is that the RFC has good reason to require this behavior on the >> server side, and any server that does not follow this requirement is >> broken and needs to be fixed. >I believe none of the common IMAP servers handle the above situation >"correctly". A server that does not keep strictly ascending unique UIDVALIDITY values is broken. All common IMAP servers that I know do this correctly. 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 ">=". Andy -- Andreas Aardal Hanssen - Binc IMAP http://www.bincimap.andreas.hanssen.name/
