On Mon, Nov 4, 2013 at 1:55 PM, Oswald Buddenhagen <[email protected]> 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. I heave unread messages, yes tons of
them some very old, why would that matter for MaxMessages?

Also, this is the first fetch, what do you mean by "preserve"?

>> Also, is there a way to not remove the older messages? So the initial
>> fetch gets MaxMessages, but later ones only sync up to MaxMessages,
>> and leave the rest untouched.
>>
> that sounds like the exact opposite of what is currently intended: it's
> trying to be a sliding window,

Yeah, I know.

> while you seem to want a simple cut-off
> with "fill up" when messages disappear.
> what is the use case?

As I have said before; I don't want to download tens of thousands of messages.

Suppose I have mailbox with 10000 messages.

I expect this:
1) First fetch CutMessages=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 now 2000 messages locally.

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.

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.

The important part in all cases is that in no point in time I had to
fetch 10000 messages, which could very well be 100000.

>> I might give a try to hash out the issues too, is there any part of
>> the code that you have an eye on?
>>
> the meat of the algorithm is in sync.c, box_loaded().

I don't think the problem is the slide window, it's the part that
determines how many messages to fetch.

-- 
Felipe Contreras

------------------------------------------------------------------------------
Android is increasing in popularity, but the open development platform that
developers love is also attractive to malware creators. Download this white
paper to learn more about secure code signing practices that can help keep
Android apps secure.
http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.clktrk
_______________________________________________
isync-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/isync-devel

Reply via email to