commit 1e7a75095b82b43c60de55890d6728f68e3e9e0e
Author: Oswald Buddenhagen
Date: Wed Nov 20 09:08:26 2024 +0100
fix crash when resuming message propagation with MaxMessages
the problem is triggered by the source-side message disappearing
after a transaction to propagate it was
On Tue, Jul 09, 2024 at 12:14:42PM GMT, Oswald Buddenhagen via isync-devel
wrote:
> yes, it was added with specifically that use case in mind.
good stuff; thanks.
and for the next wondering wanderer; also see ExpireUnread.
- Paymon
On Mon, Jul 08, 2024 at 09:48:27AM -0400, Paymon wrote:
On Mon, Jul 08, 2024 at 09:44:27AM GMT, Paymon wrote:
my case is the opposite of that^; i.e. i have a very small quota on
the server
and a fairly big amount incoming messages (mailing lists). i want to archive
the mailing list locally where
On Mon, Jul 08, 2024 at 09:44:27AM GMT, Paymon wrote:
>
> from mbsync(1):
> ```man
> MaxMessages count
> Sets the maximum number of messages to keep in each near side mailbox. This
> is useful for mailboxes where you keep a complete archive on the server, but
> want to
from mbsync(1):
```man
MaxMessages count
Sets the maximum number of messages to keep in each near side mailbox. This
is useful for mailboxes where you keep a complete archive on the server, but
want to mirror only the last messages (for instance, for mailing lists). The
messages that were the
commit 8f39d06015c7491c81f40a35703cfe78529b868f
Author: Oswald Buddenhagen
Date: Tue Feb 22 16:42:22 2022 +0100
fix mixing MaxMessages with MaxSize
this is actually a useful combination for resource-constrained devices.
NEWS | 2 +
src/run-tests.pl | 125
On Sat, Jan 08 2022, Oswald Buddenhagen wrote:
> rather "ExpireSide {Far|Near}" - more traditional syntax, and would not
> need duplication when MaxAge finally gets added.
Makes sense
>>This seems to be the only option that introduces a functional difference
>>between the near and far side.
>>
>
On Sat, Jan 08, 2022 at 03:40:41PM +0100, Yuri D'Elia wrote:
Would it be possible to have an equivalent of MaxMessages that applies
to the "far" side?
technically possible, sure. it wouldn't be even particularly hard - it's
just a matter of replacing a bunch of con
Would it be possible to have an equivalent of MaxMessages that applies
to the "far" side? Maybe by adding a qualifier in the configuration:
MaxMessages count [far|near]
or another directive?
This seems to be the only option that introduces a functional difference
between the near an
Hi Oswald,
Thank you for your quick response. That's ok. I'll take the hard way then.
On Sat, May 23, 2020 at 2:55 AM Oswald Buddenhagen <
oswald.buddenha...@gmx.de> wrote:
> On Sat, May 23, 2020 at 12:53:07AM -0700, Mike Chen wrote:
> >I'm thinking about to use
On Sat, May 23, 2020 at 12:53:07AM -0700, Mike Chen wrote:
I'm thinking about to use MaxMessages for INBOX channel and increase it
daily to have all emails downloaded.
I'd like to know if this is possible?
no, that won't work due to the way the internal accounting works.
howev
Hi
Due to the bandwidth limit of Gmail(< 2500Mb/day), I have difficulties to
download all my emails(around 10Gb). I'm thinking about to use MaxMessages
for INBOX channel and increase it daily to have all emails downloaded.
For instance,
On 5/24, I set MaxMessages 2 to download t
Dear Oswald,
> mbsync relies on the monotoneously incrementing UIDs.
> ...
Thanks for the explanation.
Best regards,
Luis
--
"Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
Instantly run your Sel
On Sun, May 18, 2014 at 10:02:25AM -0500, Luis Mochan wrote:
> I did get 100 messages, but they were not the latest nor the earliest
> but rather scattered throughout the maildir. When fetching messages
> from an actual maildir (containing actual messages instead of symbolic
> links) I did get the
Hello Oswald,
> ...as a workaround i can only suggest setting MaxMessages to the highest
> realistic number of messages you would be able to go backwards. of
> course that's not helpful if you need to work in very small increments.
>
> alternatively, you could simply dele
e don't know where the range would
start even if all messages would qualify (because there may be holes in
the numbering due to deleting messages ... though it would be a
possibility to use always-contiguous IMAP sequence numbers instead of
UIDs in this case ...).
as a workaround i can only s
Dear Oswald,
> > and then enough messages to be fetched from the master to fill again
> > the quota of the most recent 100 messages in the slave.
> >
> mbsync won't do that. it will only fetch new messages later on.
> why would you want to "work your way back"?
I usually scan my mail in FILO order
t; the quota of the most recent 100 messages in the slave.
>
mbsync won't do that. it will only fetch new messages later on.
why would you want to "work your way back"?
> From what I read, it seems to me that only using MaxMessages 100 would
> fetch all of my unread message
d from the master to fill again the quota of the
most recent 100 messages in the slave. Finally, if new messages arrive
to the master, I would the corresponding number of messages to be
deleted from the slave (not from the master) so that it ends up again
with only the 100 most recent ones.
Would &#
commit 359091625daefccfa1a957dbfb7536376a4c56fc
Author: Oswald Buddenhagen
Date: Fri Dec 13 15:36:33 2013 +0100
MaxMessages: ignore entries with no master while calculating bulk fetch
src/sync.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/src/sync.c b/src
On Wed 11 Dec 2013 at 10:41:13AM +0100, Oswald Buddenhagen wrote:
> > it makes maintaining parallel branches somewhat difficult
>
> yes, i know. sorry for that. for all i know you are the only one who
> ever maintained a branch (you still do? why? let's talk about it!),
Haha, yes this may well be
On Tue, Dec 10, 2013 at 11:17:49PM -0600, guns wrote:
> I have noticed that you have reset the master branch of
> http://sourceforge.net/projects/isync/ three times in the last month.
>
three? i don't think so.
i rewrote the history of all branches to retroactively fix a git setup
glitch (and remo
Hello Oswald,
Thank you for your continued work on mbsync. This software is extremely
valuable for working with mail accounts.
I have noticed that you have reset the master branch of
http://sourceforge.net/projects/isync/ three times in the last month.
I'm unsure why you have done this (perhaps a
hi users!
On Mon, Dec 09, 2013 at 09:01:50AM +, Oswald Buddenhagen wrote:
> The branch 'maxmessages', previously at d0167dd, has been deleted.
>
with this branch being merged now, i feel like making the next attempt
at ... wait for it ... making a release. :D
so please give i
The branch 'maxmessages', previously at d0167dd, has been deleted.
--
Sponsored by Intel(R) XDK
Develop, test and display web and hybrid apps with a single code base.
Download it for free
commit f586c0bee5aac9218fb33f44c59d031ae0e0162b
Author: Oswald Buddenhagen
Date: Sun Nov 24 19:39:33 2013 +0100
make it possible to specify CopyArrivalDate and MaxMessages globally
sneaky change on the side: the wording of the man page is changed from
"outside any sectio
commit 15216947fbc1a385d9dcca9e61bccd77ed86b58a
Author: Oswald Buddenhagen
Date: Fri Nov 8 12:05:08 2013 +0100
don't protect recent messages from MaxMessages
while maildir has a clearly defined meaning of "recent" and for example
mutt handles it graciously, IM
commit b1842617f7700c56d3eede8ce6c5afdacf433fca
Author: Oswald Buddenhagen
Date: Sat Nov 30 13:03:12 2013 +0100
make MaxMessages work for new mails as well
this helps enormously on the first sync of a 100k message box with a
limit of 1k messages. it also happens to make the
The branch 'maxmessages', previously at 69da8d8, has been rewound by 1
revision(s) and subsequently fast-forwarded by 1 revision(s) to
d0167dd.
--
Rapidly troubleshoot problems before they affect your busines
>
> ok, got it. the algorithm is broken. duh. [...]
>
> so two things to think about for me. please stand by ...
>
a week later than hoped, but i think it's done. please retry the
maxmessages branch.
The branch 'maxmessages', previously at afc19b1, has been rewound by 14
revision(s) and subsequently fast-forwarded by 30 revision(s) to
8def600.
--
Shape the Mobile Experience: Free Subscription
Software e
On Wed, Nov 20, 2013 at 08:35:52AM -0600, Felipe Contreras wrote:
> Unless you are prepared to allow some kind of voting I say there's no
> point in discussing; it's blatantly obvious you are not looking for a
> good name, you are merely looking for excuses to support the name you
> *ALREADY* chose
lt is, indeed,
> orthogonal to the name.
This is my original statement:
> Moreover you start from the assumption that people would automatically assume
> unread messages are not included in this limit, and I think it would be the
> opposite for most people.
This is a factual statement,
On Mon, Nov 18, 2013 at 06:36:52PM -0600, Felipe Contreras wrote:
> On Sun, Nov 17, 2013 at 5:36 PM, Oswald Buddenhagen wrote:
> > On Sat, Nov 16, 2013 at 04:29:01AM -0600, Felipe Contreras wrote:
> >> On Fri, Nov 15, 2013 at 4:44 PM, Oswald Buddenhagen wrote:
> >> > On Fri, Nov 15, 2013 at 02:35
On Sun, Nov 17, 2013 at 5:36 PM, Oswald Buddenhagen wrote:
> On Sat, Nov 16, 2013 at 04:29:01AM -0600, Felipe Contreras wrote:
>> On Fri, Nov 15, 2013 at 4:44 PM, Oswald Buddenhagen wrote:
>> > On Fri, Nov 15, 2013 at 02:35:44PM -0600, Felipe Contreras wrote:
>> You said this:
>>
>> >> >> >> > -
On Sat, Nov 16, 2013 at 04:29:01AM -0600, Felipe Contreras wrote:
> On Fri, Nov 15, 2013 at 4:44 PM, Oswald Buddenhagen wrote:
> > On Fri, Nov 15, 2013 at 02:35:44PM -0600, Felipe Contreras wrote:
> You said this:
>
> >> >> >> > - i didn't want to change the default behavior
>
> That's a red her
gt; > well, there are two considerations:
>> >> >> > - i didn't want to change the default behavior
>> >> >> > - i wanted to default to the safe (don't miss messages) option.
>> >> >> > though
>> >> >> > it c
gt; On Tue, Nov 12, 2013 at 05:06:08AM -0600, Felipe Contreras wrote:
> >> >> On Tue, Nov 12, 2013 at 4:40 AM, Oswald Buddenhagen
> >> >> wrote:
> >> >> > On Mon, Nov 11, 2013 at 07:05:04AM -0600, Felipe Contreras wrote:
> >>
; On Tue, Nov 12, 2013 at 4:40 AM, Oswald Buddenhagen wrote:
>> >> > On Mon, Nov 11, 2013 at 07:05:04AM -0600, Felipe Contreras wrote:
>> >> >> Oswald Buddenhagen wrote:
>> >> >> > this is now done in the maxmessages branch.
>> >> &
gt; On Mon, Nov 11, 2013 at 07:05:04AM -0600, Felipe Contreras wrote:
> >> >> Oswald Buddenhagen wrote:
> >> >> > this is now done in the maxmessages branch.
> >> >> > the option is called ExpireUnread yes/no
> >> >
> >> &
;> Oswald Buddenhagen wrote:
>> >> > this is now done in the maxmessages branch.
>> >> > the option is called ExpireUnread yes/no
>> >
>> >> you start from the assumption that people would automatically assume
>> >> unread messag
On Tue, Nov 12, 2013 at 05:06:08AM -0600, Felipe Contreras wrote:
> On Tue, Nov 12, 2013 at 4:40 AM, Oswald Buddenhagen wrote:
> > On Mon, Nov 11, 2013 at 07:05:04AM -0600, Felipe Contreras wrote:
> >> Oswald Buddenhagen wrote:
> >> > this is now done in the maxmess
On Tue, Nov 12, 2013 at 4:40 AM, Oswald Buddenhagen wrote:
> On Mon, Nov 11, 2013 at 07:05:04AM -0600, Felipe Contreras wrote:
>> Oswald Buddenhagen wrote:
>> > this is now done in the maxmessages branch.
>> > the option is called ExpireUnread yes/no
>
>> you s
On Mon, Nov 11, 2013 at 07:05:04AM -0600, Felipe Contreras wrote:
> Oswald Buddenhagen wrote:
> > this is now done in the maxmessages branch.
> > the option is called ExpireUnread yes/no
> you start from the assumption that people would automatically assume
> unread message
get higher and higher uids.
> > > incrementally extending the lower bound poses an interesting challenge.
> >
> > But that's true for both MaxMessages and MaxAge, no?
> >
> correct.
>
> > > so what are your priorities, given the effort (and consequently
the fetch from the
> server is still gigantic, because no messages have been expired on the
> slave yet, so the fetch optimization does not kick in yet. that's a
> minor problem, as at some point messages will be expired (unless the
> archive stopped growing at all, but then
yet. that's a
minor problem, as at some point messages will be expired (unless the
archive stopped growing at all, but then you wouldn't be using
MaxMessages with it to start with), but still ...
so two things to think about for me. please stand by ...
--
> If that matters for him.
>
it's not sane to require a user to fetch his entire archive to read a
few omitted messages. ;)
> > well, mbsync assumes that subsequent fetches get higher and higher uids.
> > incrementally extending the lower bound poses an interesting chall
The branch 'maxmessages', previously at a2de976, has been rewound by 10
revision(s) and subsequently fast-forwarded by 22 revision(s) to
afc19b1.
--
November Webinars for C, C++, Fortran Developers
Accelerate a
On Sat, Nov 09, 2013 at 12:23:55AM +0100, Gammel Holte wrote:
> The initial sync works fine, but after that messages sent by me are
> never downloaded from the server.
>
> I don't know whether this is a misconfiguration problem from my side
> (configuration pasted below), or an isync bug. In the l
I'm experiencing an odd issue with the maxmessages branch.
The initial sync works fine, but after that messages sent by me are
never downloaded from the server.
I don't know whether this is a misconfiguration problem from my side
(configuration pasted below), or an isync bug. In the l
gt;> but you seem to imply the messages can still be disposed for some
>> other reason.
>>
> no. "prune" is probably a better word than "expire".
> i just meant optionally loosening the definition of important:
> AlwaysFetch: Recent (provided i
uot; is probably a better word than "expire".
i just meant optionally loosening the definition of important:
AlwaysFetch: Recent (provided it's possible after all), Unread, None.
> >> Why can't MaxMessages mean the maximum amount of messages, period?
> >>
> >
7;ll put it on the todo.
Thanks.
>> > the assumption is that you wouldn't want to miss lots of messages just
>> > because you haven't been reading mail for a while.
>>
>> I have a folder with 120,000 unread messages, if I try to first fetch
>> with Max
#x27;ll put it on the todo.
> > the assumption is that you wouldn't want to miss lots of messages just
> > because you haven't been reading mail for a while.
>
> I have a folder with 120,000 unread messages, if I try to first fetch
> with MaxMessages 100, I would get 120
means.
I just think there should be a way to specify the maximum amount of
messages to sync. In fact, I would prefer it to be the maximum age,
like in offlineimap, so I can say: sync only the last month. If a
folder has a lot of traffic like LKML, and another has very low one I
might be getting up to
7;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
; 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 som
ld it be that you are not auto-marking unread messages as non-recent
("old")? mbsync preserves such messages.
ideally, if you could produce a test case in run-tests.pl, somewhere
around X30 or X50.
> Also, is there a way to not remove the older messages? So the initial
> fetch gets
On Mon, Nov 4, 2013 at 3:16 AM, Oswald Buddenhagen wrote:
> On Mon, Nov 04, 2013 at 09:07:27AM +, Oswald Buddenhagen wrote:
>> The branch 'maxmessages' has been created at a2de976.
>>
> this branch contains the commit
>
>make MaxMessages work for
Hi,
>make MaxMessages work for the initial fetch
>
> it passes my (rather limited) autotests, but this stuff is *complex*, so
> you should give it some hammering before i push it to master. it's
> implausible that it would eat your master-side mailbox, but you should
hello users,
On Mon, Nov 04, 2013 at 09:07:27AM +, Oswald Buddenhagen wrote:
> The branch 'maxmessages' has been created at a2de976.
>
this branch contains the commit
make MaxMessages work for the initial fetch
it passes my (rather limited) autotests, but this stuff is *
The branch 'maxmessages' has been created at a2de976.
--
Android is increasing in popularity, but the open development platform that
developers love is also attractive to malware creators. Download this whit
commit ba1e176717db3ea5a78c8fcbc5f2ba0f1619d356
Author: Oswald Buddenhagen
Date: Mon May 20 18:54:54 2013 +0200
MaxMessages: make condition exactly symmetrical to condition below
src/sync.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/src/sync.c b/src/sync.c
64 matches
Mail list logo
