Sam Varshavchik wrote:

[]

Sam, one slightly-related note. As I can see, this cache file contains only mapping of messagefilename <=> uuid. Why not drop it at all, and use filename as it's uuid? I.e. when we see new/hostname.timestamp file, we'll move it to cur/nnnn;flags, where nnnn is a next message number. With this, the only thing that needs to be stored is last used message number, and this is in a very small file that can be written "atomically" (i.e. using only one write, guaranteed). I know that this is a "violation" of maildir format with that other programs that have access to new/ will "not work" (or well, courier will not work with them), and one will need to have a harder deal with locking. But I doesn't see any _real_ troubles here. Can you comment this approach?

BTW, one more thing about maildir "format". Is it ok to have cur directory hashed, like e.g. spool in squid? Don't know real advantages of this, but at least one comes to mind -- server will not need to rescan the whole directory if it losts a message (in case of changed flags), but only one hashed subdir (hash by message number). I now have about 4000 messages average in my folders that are handled by courier-imapd. For now, system handles this well. Maybe if there will be more messages, I'll try to use e.g. reiserfs (all of this on linux) if access will be slow. But I'm not shure if imap protocol is sutable for handling such a folders, or at least some imap clients are -- my netscape loads folder summary (all message numbers with flags) very often, and most of the time system spend sending/receiving that data over network... (sorry for "thread offtopic" -- all this completely irrelevant for quotas).

Regards, Michael.