Re: [Dovecot] Cooperating with dovecot in its Maildir
Timo Sirainen 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
Re: [Dovecot] Cooperating with dovecot in its Maildir
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.
Re: [Dovecot] Cooperating with dovecot in its Maildir
Timo Sirainen 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
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 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.
Re: [Dovecot] Cooperating with dovecot in its Maildir
On 29.1.2011, at 2.38, Rob Browning wrote: > In this particular case, we're thinking of trying to allow notmuch to > operate directly on the dovecot Maildir, and at the moment, the only > modifications notmuch makes are to change maildir flags. Would locking > dovecot-uidlist.lock be sufficient, perhaps via liblockfile? 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. > Also, is there some reliable way to detect a dovecot Maildir? For > example, are any of the dovecot-* files guaranteed to exist all the > time? dovecot-uidlist always exists, but in some installations it's stored outside the maildir.
[Dovecot] Cooperating with dovecot in its Maildir
Is it possible to cooperate with dovecot within its Maildir, and if so, what's required? In this particular case, we're thinking of trying to allow notmuch to operate directly on the dovecot Maildir, and at the moment, the only modifications notmuch makes are to change maildir flags. Would locking dovecot-uidlist.lock be sufficient, perhaps via liblockfile? Also, is there some reliable way to detect a dovecot Maildir? For example, are any of the dovecot-* files guaranteed to exist all the time? 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
