On Sat, 2011-01-29 at 12:04 -0600, Rob Browning wrote:
I saw that, but I wasn't sure if the fact that a message might "receive a new UID" could be a problem.
It's a theoretical problem mostly, especially in your case. It's mainly visible when doing stress testing with large maildirs. I doubt in regular use it matters. Courier doesn't try to prevent it in any way and it seems to have worked mostly ok.
Or is the UID supposed to change when the flags change?
No.
OK, so it sounds like if we wanted to be completely safe, we probably need to know that we're in a dovecot Maildir, and then we need to know where to create the appropriate dovecot-uidlist.lock file whenever renaming files.
There's no good way to find out where the uidlist files are, if they're not in the maildir itself. They typically are.
Do you happen to know if the liblockfile (lockfile_create(3), etc.) .lock strategy is compatible with dovecot's approach?
Should be. It's possible though that in a future version there is no .lock file but rather the uidlist is locked directly with fcntl.