Re: [Dovecot] Cooperating with dovecot in its Maildir
On 29.1.2011, at 19.05, Rob Browning wrote:
Oops, I accidentally added you to discard list rather than accept list :)
Timo Sirainen <tss@iki.fi> writes:
If you're only changing the standard maildir flags (not a..z = keywords) then you don't really need to lock anything. The uidlist locking could prevent a mail from being temporarily lost, but this happening is highly unlikely. http://wiki2.dovecot.org/MailboxFormat/Maildir#Locking explains.
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.
Timo Sirainen <tss@iki.fi> writes:
On 29.1.2011, at 19.05, 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.
Do you happen to know if the liblockfile (lockfile_create(3), etc.) .lock strategy is compatible with dovecot's approach?
Thanks
Rob Browning rlb @defaultvalue.org and @debian.org GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4
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.
Timo Sirainen <tss@iki.fi> writes:
On Sat, 2011-01-29 at 12:04 -0600, Rob Browning wrote:
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.
Right, I was assuming we might just have to require the user to tell us whenever they're not in the normal place.
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.
OK, though as you're probably aware, there may be some issues cross-platform, and/or with shared FSs. Avery wrote an interesting summary recently:
http://apenwarr.ca/log/?m=201012#13
Thanks again
Rob Browning rlb @defaultvalue.org and @debian.org GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4
participants (2)
-
Rob Browning
-
Timo Sirainen