Andreas Aardal Hanssen writes:
Is that relevant? I actually don't, I think it's too careless, but I don't see that as relevant.On Wed, 22 Jan 2003, Arnt Gulbrandsen wrote:Exactly - so if you set the time on your computer, do you agree that conditions may be broken?Andreas Aardal Hanssen writes:If the server's persistent storage is messed up, every guarantee breaks. One example among dozens: If the server's UIDNEXT storage is hand-edited, the "UID grows" guarantee is broken.What happens if the alternative UIDVALIDITY log file gets messed up?
What I'm saying is that storing the maximum UIDVALIDITY for each past mailbox does not introduce any new failure mode. If an IMAP server runs into file system corruption, any of the following can conceivably happen:
- UIDNEXT can shrink
- folders can be spontaneously renamed
- messages or flags can change, silently invalidating client caches
- the UID of a message can change
and if the UIDVALIDITY name/value pairs are stored in a file,
- the RENAME/UIDVALIDITY guarantee can be broken
If you can accept the first four, the last one should be okay too.
So when we discuss RENAME, we can't start with "what-ifs" that don't apply exclusively to IMAP.Agreed. We should, however, try to make the IMAP features consistent with each other.
--Arnt
