comparison src/lib-storage/index/maildir/maildir-sync.c @ 6878:0c3ab0aef33c HEAD

maildir_uidlist_sync_init() was called wrong, although it just happened to work.
author Timo Sirainen <tss@iki.fi>
date Sat, 01 Dec 2007 09:09:21 +0200
parents 64e0f45e8dc3
children 724c8f12eed2
comparison
equal deleted inserted replaced
6877:a5a7d38b6df7 6878:0c3ab0aef33c
693 } 693 }
694 694
695 static int maildir_sync_context(struct maildir_sync_context *ctx, bool forced, 695 static int maildir_sync_context(struct maildir_sync_context *ctx, bool forced,
696 bool *lost_files_r) 696 bool *lost_files_r)
697 { 697 {
698 enum maildir_uidlist_sync_flags sync_flags;
698 bool new_changed, cur_changed; 699 bool new_changed, cur_changed;
699 int ret; 700 int ret;
700 701
701 *lost_files_r = FALSE; 702 *lost_files_r = FALSE;
702 703
752 because maildir doesn't require any kind of locking. Luckily this 753 because maildir doesn't require any kind of locking. Luckily this
753 problem rarely happens except under high amount of modifications. 754 problem rarely happens except under high amount of modifications.
754 */ 755 */
755 756
756 ctx->partial = !cur_changed; 757 ctx->partial = !cur_changed;
757 ret = maildir_uidlist_sync_init(ctx->mbox->uidlist, ctx->partial, 758 sync_flags = ctx->partial ? MAILDIR_UIDLIST_SYNC_PARTIAL : 0;
759 ret = maildir_uidlist_sync_init(ctx->mbox->uidlist, sync_flags,
758 &ctx->uidlist_sync_ctx); 760 &ctx->uidlist_sync_ctx);
759 if (ret <= 0) { 761 if (ret <= 0) {
760 /* failure / timeout. if forced is TRUE, we could still go 762 /* failure / timeout. if forced is TRUE, we could still go
761 forward and check only for renamed files, but is it worth 763 forward and check only for renamed files, but is it worth
762 the trouble? .. */ 764 the trouble? .. */