On Fri, Jul 31, 2009 at 01:34:59PM -0400, Timo Sirainen wrote:
Thanks for your explanations and patience Timo!
--
Thomas Hummel | Institut Pasteur
| Pôle informatique - systèmes et réseau
On Fri, 2009-07-31 at 19:27 +0200, Thomas Hummel wrote:
> On Fri, Jul 31, 2009 at 01:22:37PM -0400, Timo Sirainen wrote:
>
> > Because client thinks UID = message. If a message's UID changes, the
> > client has no idea that it's still the same message.
>
> Yes but what does and UID has changes fr
On Fri, Jul 31, 2009 at 01:22:37PM -0400, Timo Sirainen wrote:
> Because client thinks UID = message. If a message's UID changes, the
> client has no idea that it's still the same message.
Yes but what does and UID has changes from the client pint of view then ? You
mean something like, in its c
On Fri, Jul 31, 2009 at 01:20:17PM -0400, Timo Sirainen wrote:
> Well, that's pretty much the same thing. I meant that if Dovecots on
> both servers touch the same mailbox at the same time, there are caching
> problems. Regardless of what part of Dovecot touches it.
Of course, sorry, I'm not used
On Fri, 2009-07-31 at 19:20 +0200, Thomas Hummel wrote:
> On Fri, Jul 31, 2009 at 01:18:17PM -0400, Timo Sirainen wrote:
>
> > Depends on client.
>
> Ok but I don't understand why you say that a client, though caching UID and
> UIDVALIDITY, makes no difference between a new message and some UID c
On Fri, Jul 31, 2009 at 01:18:17PM -0400, Timo Sirainen wrote:
> Depends on client.
Ok but I don't understand why you say that a client, though caching UID and
UIDVALIDITY, makes no difference between a new message and some UID change on
the server ?
--
Thomas Hummel | Institut Pasteur
|
On Fri, 2009-07-31 at 19:17 +0200, Thomas Hummel wrote:
> > BTW. If you're going to run Postfix on both servers and both deliver
> > mails to any users, you're still going to have the same caching problems
> > if you're using Dovecot's deliver.
>
> No, I'm going to run postfix on one, dovecot on t
On Fri, 2009-07-31 at 19:15 +0200, Thomas Hummel wrote:
> On Fri, Jul 31, 2009 at 01:00:10PM -0400, Timo Sirainen wrote:
>
> > Then again, client doesn't know if UID changes. It handles those
> > situations exactly the same way as if message was expunged and a new
> > message was added.
>
> So on
On Fri, Jul 31, 2009 at 01:15:07PM -0400, Timo Sirainen wrote:
> Right, it'll easily cause all kinds of caching related problems even
> with the mail_nfs_*=yes settings (which also slow things down).
Ok.
> And some users use multiple clients.
That's right.
> BTW. If you're going to run Postfix
On Fri, Jul 31, 2009 at 01:00:10PM -0400, Timo Sirainen wrote:
> Then again, client doesn't know if UID changes. It handles those
> situations exactly the same way as if message was expunged and a new
> message was added.
So on what criteria does a client fetch a message ? Does it just ask anythi
On Fri, 2009-07-31 at 19:08 +0200, Thomas Hummel wrote:
> Another solution would be to DNS round-robin on 2 servers runing dovecot but I
> think I've read on the dovecot wiki that it wasn't a good idea. Instead, I
> understood that I could use the IMAP proxy to send the same user on the same
> serv
On Fri, Jul 31, 2009 at 01:07:30PM -0400, Timo Sirainen wrote:
> OK. It just sounded like you were thinking about putting index files to
> NFS and control files to local disk.
At first I thought about it. But this thread made me understand why it was
stupid. Thanks.
--
Thomas Hummel | In
On Fri, Jul 31, 2009 at 07:04:32PM +0200, Thomas Hummel wrote:
> Since I plan to split dovecot and postfix on 2 different servers but want to
> be
> able to use anyone of them back to run both postfix and dovecot if one of them
> crash, I plan to put indexes and control files on NFS.
Another sol
On Fri, 2009-07-31 at 19:04 +0200, Thomas Hummel wrote:
> On Fri, Jul 31, 2009 at 01:00:38PM -0400, Timo Sirainen wrote:
> > > In a setup like mine where INDEXES and CONTROL point to different places
> > > for instance.
> > > Is there something wrong with such a solution ?
> >
> > But aren't bo
On Fri, Jul 31, 2009 at 01:00:38PM -0400, Timo Sirainen wrote:
> > In a setup like mine where INDEXES and CONTROL point to different places
> > for instance.
> > Is there something wrong with such a solution ?
>
> But aren't both of them in local disk then?
No. At the moment, the Maildirs and
On Fri, 2009-07-31 at 18:59 +0200, Thomas Hummel wrote:
> On Fri, Jul 31, 2009 at 12:50:11PM -0400, Timo Sirainen wrote:
>
> > But I still don't understand how you could lose dovecot-uidlist but not
> > indexes.
>
> In a setup like mine where INDEXES and CONTROL point to different places for
> i
On Fri, 2009-07-31 at 18:56 +0200, Thomas Hummel wrote:
> On Fri, Jul 31, 2009 at 12:49:04PM -0400, Timo Sirainen wrote:
>
> > Most clients cache mails based on UIDVALIDITY and UID, so if UIDVALIDITY
> > changes, it re-downloads all mails. If just UIDs change, then it's
> > handled exactly the sam
On Fri, Jul 31, 2009 at 12:50:11PM -0400, Timo Sirainen wrote:
> But I still don't understand how you could lose dovecot-uidlist but not
> indexes.
In a setup like mine where INDEXES and CONTROL point to different places for
instance.
Is there something wrong with such a solution ?
--
Thomas
On Fri, Jul 31, 2009 at 12:49:04PM -0400, Timo Sirainen wrote:
> Most clients cache mails based on UIDVALIDITY and UID, so if UIDVALIDITY
> changes, it re-downloads all mails. If just UIDs change, then it's
> handled exactly the same way as if all messages just got expunged and
> added back, so ag
On Fri, 2009-07-31 at 18:48 +0200, Thomas Hummel wrote:
> On Fri, Jul 31, 2009 at 12:26:04PM -0400, Timo Sirainen wrote:
>
> So, to come back at my initial question :
>
> Is it correct to say that what's wrong in dovecot-uidlist lost is the
> potential
> lost of UIDVALIDITY and nextUID (if inde
On Fri, 2009-07-31 at 18:40 +0200, Thomas Hummel wrote:
> On Fri, Jul 31, 2009 at 12:26:04PM -0400, Timo Sirainen wrote:
>
> > i.e. Dovecot gets also the next_uid from index file, and starts
> > assigning UIDs beginning from it.
>
> Clear. I probably deleted indexes as well in my test and didn't
On Fri, Jul 31, 2009 at 12:26:04PM -0400, Timo Sirainen wrote:
So, to come back at my initial question :
Is it correct to say that what's wrong in dovecot-uidlist lost is the potential
lost of UIDVALIDITY and nextUID (if indexes are deleted as well) ?
I mean dovecot-uidlist lost alone has not m
On Fri, Jul 31, 2009 at 12:26:04PM -0400, Timo Sirainen wrote:
> i.e. Dovecot gets also the next_uid from index file, and starts
> assigning UIDs beginning from it.
Clear. I probably deleted indexes as well in my test and didn't notice a new
UIDVALIDITY.
But what about the client's cache ? Does
On Fri, 2009-07-31 at 18:15 +0200, Thomas Hummel wrote:
> On Fri, Jul 31, 2009 at 11:30:30AM -0400, Timo Sirainen wrote:
>
> > For example if you have mails with
> > UIDs 1, 2, 5 and 10 and you delete dovecot-uidlist and dovecot.index*,
> > Dovecot gives them UIDs 1, 2, 3, 4.
>
> Ok, I get it
On Fri, Jul 31, 2009 at 11:30:30AM -0400, Timo Sirainen wrote:
> For example if you have mails with
> UIDs 1, 2, 5 and 10 and you delete dovecot-uidlist and dovecot.index*,
> Dovecot gives them UIDs 1, 2, 3, 4.
Ok, I get it.
But the only way I can think of a client can detect that UIDs are
On Jul 31, 2009, at 5:25 AM, Thomas Hummel wrote:
On Thu, Jul 30, 2009 at 01:21:40PM -0400, Timo Sirainen wrote:
Just dovecot-uidlist, or also dovecot.index*?
Just dovecot-uidlist.
Then I don't really get it. You want to store index files on NFS, but
not control files? Doesn't really mak
On Jul 31, 2009, at 4:47 AM, Thomas Hummel wrote:
and the result is that opening a message from
list opens a completely different mail)
That I don't get since, even if UIDALIDITY change, and even if new
messages
arrive in the mailbox between dovecot-uidlist erasement and
recreation, since
On Thu, Jul 30, 2009 at 01:21:40PM -0400, Timo Sirainen wrote:
> Just dovecot-uidlist, or also dovecot.index*?
Just dovecot-uidlist.
> If you delete both, UIDVALIDITY is changed. If you delete only
> dovecot-uidlist, it'll probably preserve UIDVALIDITY and just give new UIDs
> to messages (beca
On Thu, Jul 30, 2009 at 01:33:27PM -0400, Timo Sirainen wrote:
> I think it's a bad idea. Besides the UID problems causing all kinds of
> trouble with clients (some clients ignore UIDVALIDITY completely (Apple
> Mail, at least used to)
Woah! That's indeed stupid from them...
> and the result is
On Thu, 2009-07-30 at 19:24 +0200, Thomas Hummel wrote:
> I'm asking this because I'm investigating if CONTROL may be on a local
> filesystem (for performance reason) instead of an NFS filesystem :
I think it's a bad idea. Besides the UID problems causing all kinds of
trouble with clients (some cl
On Thu, Jul 30, 2009 at 07:04:01PM +0200, Thomas Hummel wrote:
> On Tue, Jul 28, 2009 at 07:30:27PM +0200, Thomas Hummel wrote:
>
> > I took for granted that it was that the client would download all messages
> > again since it might be confused by some UID changes.
>
> Is it correct ? Timo ?
>
On Tue, 2009-07-28 at 19:30 +0200, Thomas Hummel wrote:
> Hello,
>
> I'm trying to figure out what exactly (and why) are the consequences of a lost
> or removal of the dovecot-uidlist file on an IMAP client (Thunderbird for
> instance).
Just dovecot-uidlist, or also dovecot.index*? If you delete
On Tue, Jul 28, 2009 at 07:30:27PM +0200, Thomas Hummel wrote:
> I took for granted that it was that the client would download all messages
> again since it might be confused by some UID changes.
Is it correct ? Timo ?
> But I don't really see
> why (on the IMAP protocol level) and I don't kno
Hello,
I'm trying to figure out what exactly (and why) are the consequences of a lost
or removal of the dovecot-uidlist file on an IMAP client (Thunderbird for
instance).
I took for granted that it was that the client would download all messages
again since it might be confused by some UID change
34 matches
Mail list logo
