mbsync

Commit Graph

Author	SHA1	Message	Date
Oswald Buddenhagen	29a56e2dc4	don't fsync after logging every TUID as we now don't actually start propagating new messages until all TUIDs have been generated, it's sufficient to sync just once. this makes it a cheap operation, so we can do it at SYNC_NORMAL level already.	11 years ago
Oswald Buddenhagen	8d5bd62537	add ExpireUnread option	11 years ago
Oswald Buddenhagen	c0ba0c7ecf	replace global_* with a channel_conf_t instance this makes the (growing) list of getopt_helper()'s parameters manageable. the few wasted bytes are worth it.	11 years ago
Oswald Buddenhagen	49a32910a7	move handling of new messages after that of old ones i.e., move it back. whatever the original reason was, it's now gone. this order is way more natural, which allows us to remove the osrecadd and S_DONE hacks.	11 years ago
Oswald Buddenhagen	b1842617f7	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 syncing idempotent. in a few conditionals we now explicitly test for max_messages being enabled, not smaxxuid != 0, as after the initial fetch with no important messages smaxxuid is zero, but we still have to skip over 99k messages in the above case.	11 years ago
Oswald Buddenhagen	d3f6347021	delay propagation of new messages previous sequence: examine & propagate new => examine old => propagate old new sequence: examine new => examine old => propagate new => propagate old this alone does not buy us much ...	11 years ago
Oswald Buddenhagen	391ec01f28	make message propagation recording less magic assign the sync record to the source message asap, and later on rely on a more explicit condition than not doing so.	11 years ago
Oswald Buddenhagen	7f784fd235	log maxuid bumping less aggressively we can bump the internal variable whereever convenient, but we cannot log it until we know that all messages were copied, as otherwise we could miss some new messages after an interruption. with the new approach, interruption would merely cause some additonal traffic.	11 years ago
Oswald Buddenhagen	8b76412b0d	document message expiration transactions	11 years ago
Oswald Buddenhagen	ecb4c7ab07	propagate deletions with other flag changes less code duplication, more logical order of issued driver commands (especially after the next commit), and the "side effect" of letting the message expiration code see those deletions if they are asynchronous.	11 years ago
Oswald Buddenhagen	273ac899f3	don't delay loading master even if messages were expired the delay optimized the corner case of previously important but now expired messages on the slave disappearing, either through an external expunge or after a journal replay. no point in pessimizing the common case.	11 years ago
Oswald Buddenhagen	12676f28da	remove cleanup of expired entries during setup of master load the removed code would only ever trigger if a) we were after a journal replay or b) something external expunged the expired messages - both are corner cases not worth the extra code. however, this means that the syncing code further down now needs to take care of these zombies. in the end, the normal cleanup will take care of all expired entries, new and old.	11 years ago
Oswald Buddenhagen	9a62521cff	micro-optimization/-clarification: swap condition order	11 years ago
Oswald Buddenhagen	014d9b9081	make message counting in expiration code less confusing	11 years ago
Oswald Buddenhagen	83b834cdfd	count unread messages like flagged messages when expiring that is, don't count them towards the total only below the cut-off point. making them extend the working set even though they are inside it is counterintuitive.	11 years ago
Oswald Buddenhagen	9e186ae88b	use post-sync "seen" flag to determine expirability otherwise it wouldn't be idempotent.	11 years ago
Oswald Buddenhagen	15216947fb	don't protect recent messages from MaxMessages while maildir has a clearly defined meaning of "recent" and for example mutt handles it graciously, IMAP's definition is fubared to the point that some servers (for example gmail) simply refuse to support it. for symmetry reasons it is best to pretend that it doesn't exist at all. it doesn't seem too useful anyway (the user can simply mark the messages as read to allow pruning). and last but not least, the man page of mbsync says nothing about "recent", only "unread". unlike the isync man page, though.	11 years ago
Oswald Buddenhagen	6b7b2b1106	always get slave flags when we are expiring even if we are not propagating new messages, the appearance of new messages on the slave can lead to expiring older messages. for that, we need to know their importance, and thus flags. the alternative would be not doing an expiration run when not fetching new messages, but that would mean more conditionals all over the place. as the decision is somewhat arbitrary, just do the simpler thing.	11 years ago
Oswald Buddenhagen	f1eea7d9a5	do not trash expired messages we are not actually deleting them, so there is no point in saving them in the trash.	11 years ago
Oswald Buddenhagen	48754ecc74	make sync state header format less obscure the header is not space-critical, so use proper name-value pairs. this has the additional advantage that subsequent format changes can be done much easier.	11 years ago
Oswald Buddenhagen	3dcb393de2	set srec->msg[] when finding messages by tuid otherwise we would propagate phantom deletions. this affected only sync runs after an interruption while storing messages, so it went (mostly?) unnoticed.	11 years ago
Oswald Buddenhagen	3814f19661	remove pointless assignment we already know that tmsg->srec is null at this point.	11 years ago
Oswald Buddenhagen	e63e16ab45	assert no stray TUIDs	11 years ago
Oswald Buddenhagen	32def5dc0a	add/fix comments and improve debug messages	11 years ago
Oswald Buddenhagen	a9a331c98a	simplify condition ... and document the cases.	11 years ago
Oswald Buddenhagen	03f8bfdfb2	micro-optimization/-clarification	11 years ago
Oswald Buddenhagen	00076a6971	move initializations for clarity	11 years ago
Oswald Buddenhagen	61ef099cd5	MaxMessages: make condition exactly symmetrical to condition below	11 years ago
Oswald Buddenhagen	080740f867	rewrite condition for readability and consistency	11 years ago
Oswald Buddenhagen	b10fd0c21c	remove assumption about value of M constant	11 years ago
Oswald Buddenhagen	a893cba483	fix enum abuse amends `9c86ec344`. S_FIND was for the sync record status field. it has no business in the sync vars status fields. its value coincided with ST_SELECTED, which luckily only means that we always tried to match up TUIDs even if there was nothing to do. the need for TUID matching arises in two mostly independent circumstances, so add two separate flags ST_FIND_{OLD,NEW}.	11 years ago
Oswald Buddenhagen	0b59ee0df3	support multi-character path separators this applies to both the IMAP PathDelimiter (which is needed by Lotus Domino), as well as the Flatten-ed separators.	12 years ago
Oswald Buddenhagen	eb1f10762f	added sync support for the arrival date of messages initial patch by Marc Hoersken <info@marc-hoersken.de>	12 years ago
Oswald Buddenhagen	6577bf3e61	warn if we cannot find some messages by TUID	12 years ago
Oswald Buddenhagen	1847a4e12d	make better use of ATTR_UNUSED	12 years ago
Oswald Buddenhagen	5ad83b4e6a	don't unnecessarily use continue	12 years ago
Oswald Buddenhagen	e4243debb6	use INT_MAX instead of zero for "no size limit" this simplifies the actual conditions	12 years ago
Oswald Buddenhagen	ca3a319e60	update copyrights	12 years ago
Oswald Buddenhagen	9261897629	don't record newuid in the sync state this value is only ever used to find just pushed messages by TUID, so we can simply use the UIDNEXT value from before we started pushing - and of course, we need to record that in the journal. it makes no sense to log the new value after completing a search, as there won't be a next search before we push the next messages.	12 years ago
Oswald Buddenhagen	96be183acb	rename sync_vars_t::uidnext => newuid & fix comment the purpose of this variable is to hold the UIDNEXT value from before we started pushing new messages, i.e., the minimal uid we can expect them to have.	12 years ago
Oswald Buddenhagen	d7eae525bd	fix TrashRemoteNew copy direction	12 years ago
Oswald Buddenhagen	35851f133b	add option to control amount of fsync()ing	12 years ago
Oswald Buddenhagen	49223b2df2	avoid that a system crash can cause messages to be propagated twice fdatasync() the journal after creating the pair record and recording the TUID, but before the message propagation actually starts. all other writes to the journal are not flushed, as they will at worst cause some unnecessary network traffic without visible effect.	12 years ago
Oswald Buddenhagen	df6c3b64b7	avoid that a system crash can clobber the sync state file make sure that the new state is committed to disk before overwriting the old version - by default meta data is committed first, so we may end up with no valid state at all otherwise.	12 years ago
Oswald Buddenhagen	f11504aa07	update copyrights make the wrapper's help string also mention copyrights pertaining only to the actual syncer, as this is the only string many people will ever see.	13 years ago
Oswald Buddenhagen	d4c786823d	replace FSF address with something more ... contemporary	13 years ago
Oswald Buddenhagen	6d49c343fc	use a hash table for message => sync record lookup this removes the pathological O(<number of sync records> * <number of new messages>) case at the cost of being a bit more cpu-intensive (but O(<number of all messages>)) for old messages.	13 years ago
Oswald Buddenhagen	dfd7516b9a	introduce ability to flatten the hierarchy of Stores	13 years ago
Oswald Buddenhagen	343f16771a	don't crash when select() on master fails synchronously svars->drv[S] would not be initialized yet, so cancel_sync() would crash.	13 years ago
Oswald Buddenhagen	28cccf4b35	fix error handling of invalid SyncState * when we find that the store is incompatible with in-store sync state, we want to fail the whole channel. however, we must not claim that the store died, otherwise it won't be disposed of properly.	13 years ago

1 2 3 4

184 Commits (c3350753b0e3a256ccbd6eeb5924f7089b7a77f1)