On Mon, Nov 04, 2013 at 02:17:15PM -0600, Felipe Contreras wrote:
> On Mon, Nov 4, 2013 at 1:55 PM, Oswald Buddenhagen <o...@kde.org> wrote:
> > On Mon, Nov 04, 2013 at 12:36:11PM -0600, Felipe Contreras wrote:
> >> I'm giving this a try, and so far it does indeed work, but only for
> >> some folders. It seems to me that the folders that fail are the ones
> >> that have older messages.
> >>
> > can you describe that more precisely?
> > could it be that you are not auto-marking unread messages as non-recent
> > ("old")? mbsync preserves such messages.
>
> I don't understand what you mean.
>
there are three levels of "noticing" messages: "read", "seen" ("old",
seen them in the mail index), and "recent" ("new", don't know about
their existence). undownloaded unread messages are assumed to be recent,
because there is no reliable way to tell differently.
it would be conceivable to add a mode where the local recency status is
ignored, so messages cannot be expired just because you opened the
mailbox.
mutt also has a mode where it doesn't mark messages as non-recent
despite viewing the index. that's what i meant above.
> I heave unread messages, yes tons of them some very old, why would
> that matter for MaxMessages?
>
the algorithm never expires recent messages.
> Also, this is the first fetch, what do you mean by "preserve"?
>
unread undownloaded messages are assumed to be recent, so consistently
with the non-expiration they are also always downloaded.
the assumption is that you wouldn't want to miss lots of messages just
because you haven't been reading mail for a while.
it would be conceivable to add modes with lower levels of safety, which
could be useful for "optional" mailboxes. option UnseenMessages:
- Fetch: the current behavior. makes sure you miss no message.
- Keep: keep already downloaded recent messages, but don't always fetch
old unread ones. that means that the initial fetch will be (mostly *)
hard-limited, but the box will grow if you regularly sync but don't
even look at your mail. if you don't sync for longer than it takes to
fill the window, there will be a "hole".
- Expire: recent mails are not different than seen ones. the box is
(mostly *) hard-limited all the time.
*) flagged messages are also never expired.
> > what is the use case?
>
> As I have said before; I don't want to download tens of thousands of
> messages.
>
that's obvious. that's what MaxMessages is all about.
> Suppose I have mailbox with 10000 messages.
> [...]
> And maybe even this:
> 1) First fetch CutMessages=1000, I get the last 1000 messages
> 2) CutMessages=2000, now I get the last 2000 messages
> 3) Subsequent fetches get the new messages after that, say over one
> month 1000 new messages more
>
> I have now 3000 messages locally.
>
i don't understand the point of that. it seems arbitrary to limit the
initial fetch to a smaller number of messages than you want to keep
in the long run.
> Currently:
> 1) First fetch MaxMessages=1000, I get the last 1000 messages
> 2) Subsequent fetches get the new messages after that, say over one
> month 1000 new messages more
>
> I have 1000 messages locally.
>
yes. what's wrong with that?
------------------------------------------------------------------------------
November Webinars for C, C++, Fortran Developers
Accelerate application performance with scalable programming models. Explore
techniques for threading, error checking, porting, and tuning. Get the most
from the latest Intel processors and coprocessors. See abstracts and register
http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk
_______________________________________________
isync-devel mailing list
isync-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/isync-devel
