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.