maildir-sync.c revision c282435b57b6f9696fc12d99ea70468b7bdfe24c
0cb2e8eb55e70f8ebe1e8349bdf49e4cbe5d8834Timo Sirainen/* Copyright (C) 2004 Timo Sirainen */
0cb2e8eb55e70f8ebe1e8349bdf49e4cbe5d8834Timo Sirainen Here's a description of how we handle Maildir synchronization and
0cb2e8eb55e70f8ebe1e8349bdf49e4cbe5d8834Timo Sirainen it's problems:
0cb2e8eb55e70f8ebe1e8349bdf49e4cbe5d8834Timo Sirainen We want to be as efficient as we can. The most efficient way to
0cb2e8eb55e70f8ebe1e8349bdf49e4cbe5d8834Timo Sirainen check if changes have occured is to stat() the new/ and cur/
0cb2e8eb55e70f8ebe1e8349bdf49e4cbe5d8834Timo Sirainen directories and uidlist file - if their mtimes haven't changed,
0cb2e8eb55e70f8ebe1e8349bdf49e4cbe5d8834Timo Sirainen there's no changes and we don't need to do anything.
0cb2e8eb55e70f8ebe1e8349bdf49e4cbe5d8834Timo Sirainen Problem 1: Multiple changes can happen within a single second -
0cb2e8eb55e70f8ebe1e8349bdf49e4cbe5d8834Timo Sirainen nothing guarantees that once we synced it, someone else didn't just
0cb2e8eb55e70f8ebe1e8349bdf49e4cbe5d8834Timo Sirainen then make a modification. Such modifications wouldn't get noticed
0cb2e8eb55e70f8ebe1e8349bdf49e4cbe5d8834Timo Sirainen until a new modification occured later.
0cb2e8eb55e70f8ebe1e8349bdf49e4cbe5d8834Timo Sirainen Problem 2: Syncing cur/ directory is much more costly than syncing
0cb2e8eb55e70f8ebe1e8349bdf49e4cbe5d8834Timo Sirainen new/. Moving mails from new/ to cur/ will always change mtime of
0cb2e8eb55e70f8ebe1e8349bdf49e4cbe5d8834Timo Sirainen cur/ causing us to sync it as well.
0cb2e8eb55e70f8ebe1e8349bdf49e4cbe5d8834Timo Sirainen Problem 3: We may not be able to move mail from new/ to cur/
0cb2e8eb55e70f8ebe1e8349bdf49e4cbe5d8834Timo Sirainen because we're out of quota, or simply because we're accessing a
0cb2e8eb55e70f8ebe1e8349bdf49e4cbe5d8834Timo Sirainen read-only mailbox.
0cb2e8eb55e70f8ebe1e8349bdf49e4cbe5d8834Timo Sirainen MAILDIR_SYNC_SECS
0cb2e8eb55e70f8ebe1e8349bdf49e4cbe5d8834Timo Sirainen -----------------
0cb2e8eb55e70f8ebe1e8349bdf49e4cbe5d8834Timo Sirainen Several checks below use MAILDIR_SYNC_SECS, which should be maximum
0cb2e8eb55e70f8ebe1e8349bdf49e4cbe5d8834Timo Sirainen clock drift between all computers accessing the maildir (eg. via
0cb2e8eb55e70f8ebe1e8349bdf49e4cbe5d8834Timo Sirainen NFS), rounded up to next second. Our default is 1 second, since
0cb2e8eb55e70f8ebe1e8349bdf49e4cbe5d8834Timo Sirainen everyone should be using NTP.
0cb2e8eb55e70f8ebe1e8349bdf49e4cbe5d8834Timo Sirainen Note that setting it to 0 works only if there's only one computer
0cb2e8eb55e70f8ebe1e8349bdf49e4cbe5d8834Timo Sirainen accessing the maildir. It's practically impossible to make two
0cb2e8eb55e70f8ebe1e8349bdf49e4cbe5d8834Timo Sirainen clocks _exactly_ synchronized.
0cb2e8eb55e70f8ebe1e8349bdf49e4cbe5d8834Timo Sirainen It might be possible to only use file server's clock by looking at
0cb2e8eb55e70f8ebe1e8349bdf49e4cbe5d8834Timo Sirainen the atime field, but I don't know how well that would actually work.
0cb2e8eb55e70f8ebe1e8349bdf49e4cbe5d8834Timo Sirainen cur directory
0cb2e8eb55e70f8ebe1e8349bdf49e4cbe5d8834Timo Sirainen -------------
0cb2e8eb55e70f8ebe1e8349bdf49e4cbe5d8834Timo Sirainen We have dirty_cur_time variable which is set to cur/ directory's
0cb2e8eb55e70f8ebe1e8349bdf49e4cbe5d8834Timo Sirainen mtime when it's >= time() - MAILDIR_SYNC_SECS and we _think_ we have
0cb2e8eb55e70f8ebe1e8349bdf49e4cbe5d8834Timo Sirainen synchronized the directory.
0cb2e8eb55e70f8ebe1e8349bdf49e4cbe5d8834Timo Sirainen When dirty_cur_time is non-zero, we don't synchronize the cur/
0cb2e8eb55e70f8ebe1e8349bdf49e4cbe5d8834Timo Sirainen directory until
0cb2e8eb55e70f8ebe1e8349bdf49e4cbe5d8834Timo Sirainen a) cur/'s mtime changes
0cb2e8eb55e70f8ebe1e8349bdf49e4cbe5d8834Timo Sirainen b) opening a mail fails with ENOENT
0cb2e8eb55e70f8ebe1e8349bdf49e4cbe5d8834Timo Sirainen c) time() > dirty_cur_time + MAILDIR_SYNC_SECS
0cb2e8eb55e70f8ebe1e8349bdf49e4cbe5d8834Timo Sirainen This allows us to modify the maildir multiple times without having
0cb2e8eb55e70f8ebe1e8349bdf49e4cbe5d8834Timo Sirainen to sync it at every change. The sync will eventually be done to
0cb2e8eb55e70f8ebe1e8349bdf49e4cbe5d8834Timo Sirainen make sure we didn't miss any external changes.
0cb2e8eb55e70f8ebe1e8349bdf49e4cbe5d8834Timo Sirainen The dirty_cur_time is set when:
0cb2e8eb55e70f8ebe1e8349bdf49e4cbe5d8834Timo Sirainen - we change message flags
0cb2e8eb55e70f8ebe1e8349bdf49e4cbe5d8834Timo Sirainen - we expunge messages
0cb2e8eb55e70f8ebe1e8349bdf49e4cbe5d8834Timo Sirainen - we move mail from new/ to cur/
0cb2e8eb55e70f8ebe1e8349bdf49e4cbe5d8834Timo Sirainen - we sync cur/ directory and it's mtime is >= time() - MAILDIR_SYNC_SECS
0cb2e8eb55e70f8ebe1e8349bdf49e4cbe5d8834Timo Sirainen It's unset when we do the final syncing, ie. when mtime is
0cb2e8eb55e70f8ebe1e8349bdf49e4cbe5d8834Timo Sirainen older than time() - MAILDIR_SYNC_SECS.
0cb2e8eb55e70f8ebe1e8349bdf49e4cbe5d8834Timo Sirainen new directory
0cb2e8eb55e70f8ebe1e8349bdf49e4cbe5d8834Timo Sirainen -------------
0cb2e8eb55e70f8ebe1e8349bdf49e4cbe5d8834Timo Sirainen If new/'s mtime is >= time() - MAILDIR_SYNC_SECS, always synchronize
0cb2e8eb55e70f8ebe1e8349bdf49e4cbe5d8834Timo Sirainen it. dirty_cur_time-like feature might save us a few syncs, but
0cb2e8eb55e70f8ebe1e8349bdf49e4cbe5d8834Timo Sirainen that might break a client which saves a mail in one connection and
0cb2e8eb55e70f8ebe1e8349bdf49e4cbe5d8834Timo Sirainen tries to fetch it in another one. new/ directory is almost always
0cb2e8eb55e70f8ebe1e8349bdf49e4cbe5d8834Timo Sirainen empty, so syncing it should be very fast anyway. Actually this can
0cb2e8eb55e70f8ebe1e8349bdf49e4cbe5d8834Timo Sirainen still happen if we sync only new/ dir while another client is also
0cb2e8eb55e70f8ebe1e8349bdf49e4cbe5d8834Timo Sirainen moving mails from it to cur/ - it takes us a while to see them.
0cb2e8eb55e70f8ebe1e8349bdf49e4cbe5d8834Timo Sirainen That's pretty unlikely to happen however, and only way to fix it
0cb2e8eb55e70f8ebe1e8349bdf49e4cbe5d8834Timo Sirainen would be to always synchronize cur/ after new/.
0cb2e8eb55e70f8ebe1e8349bdf49e4cbe5d8834Timo Sirainen Normally we move all mails from new/ to cur/ whenever we sync it. If
0cb2e8eb55e70f8ebe1e8349bdf49e4cbe5d8834Timo Sirainen it's not possible for some reason, we mark the mail with "probably
0cb2e8eb55e70f8ebe1e8349bdf49e4cbe5d8834Timo Sirainen exists in new/ directory" flag.
0cb2e8eb55e70f8ebe1e8349bdf49e4cbe5d8834Timo Sirainen If rename() still fails because of ENOSPC or EDQUOT, we still save
0cb2e8eb55e70f8ebe1e8349bdf49e4cbe5d8834Timo Sirainen the flag changes in index with dirty-flag on. When moving the mail
0cb2e8eb55e70f8ebe1e8349bdf49e4cbe5d8834Timo Sirainen to cur/ directory, or when we notice it's already moved there, we
0cb2e8eb55e70f8ebe1e8349bdf49e4cbe5d8834Timo Sirainen apply the flag changes to the filename, rename it and remove the
0cb2e8eb55e70f8ebe1e8349bdf49e4cbe5d8834Timo Sirainen dirty flag. If there's dirty flags, this should be tried every time
0cb2e8eb55e70f8ebe1e8349bdf49e4cbe5d8834Timo Sirainen after expunge or when closing the mailbox.
0cb2e8eb55e70f8ebe1e8349bdf49e4cbe5d8834Timo Sirainen This file contains UID <-> filename mappings. It's updated only when
0cb2e8eb55e70f8ebe1e8349bdf49e4cbe5d8834Timo Sirainen new mail arrives, so it may contain filenames that have already been
0cb2e8eb55e70f8ebe1e8349bdf49e4cbe5d8834Timo Sirainen deleted. Updating is done by getting uidlist.lock file, writing the
0cb2e8eb55e70f8ebe1e8349bdf49e4cbe5d8834Timo Sirainen whole uidlist into it and rename()ing it over the old uidlist. This
0cb2e8eb55e70f8ebe1e8349bdf49e4cbe5d8834Timo Sirainen means there's no need to lock the file for reading.
0cb2e8eb55e70f8ebe1e8349bdf49e4cbe5d8834Timo Sirainen Whenever uidlist is rewritten, it's mtime must be larger than the old
0cb2e8eb55e70f8ebe1e8349bdf49e4cbe5d8834Timo Sirainen one's. Use utime() before rename() if needed. Note that inode checking
0cb2e8eb55e70f8ebe1e8349bdf49e4cbe5d8834Timo Sirainen wouldn't have been sufficient as inode numbers can be reused.
0cb2e8eb55e70f8ebe1e8349bdf49e4cbe5d8834Timo Sirainen This file is usually read the first time you need to know filename for
0cb2e8eb55e70f8ebe1e8349bdf49e4cbe5d8834Timo Sirainen given UID. After that it's not re-read unless new mails come that we
0cb2e8eb55e70f8ebe1e8349bdf49e4cbe5d8834Timo Sirainen don't know about.
0cb2e8eb55e70f8ebe1e8349bdf49e4cbe5d8834Timo Sirainen broken clients
0cb2e8eb55e70f8ebe1e8349bdf49e4cbe5d8834Timo Sirainen --------------
0cb2e8eb55e70f8ebe1e8349bdf49e4cbe5d8834Timo Sirainen Originally the middle identifier in Maildir filename was specified
0cb2e8eb55e70f8ebe1e8349bdf49e4cbe5d8834Timo Sirainen only as <process id>_<delivery counter>. That however created a
0cb2e8eb55e70f8ebe1e8349bdf49e4cbe5d8834Timo Sirainen problem with randomized PIDs which made it possible that the same
0cb2e8eb55e70f8ebe1e8349bdf49e4cbe5d8834Timo Sirainen PID was reused within one second.
0cb2e8eb55e70f8ebe1e8349bdf49e4cbe5d8834Timo Sirainen So if within one second a mail was delivered, MUA moved it to cur/
0cb2e8eb55e70f8ebe1e8349bdf49e4cbe5d8834Timo Sirainen and another mail was delivered by a new process using same PID as
0cb2e8eb55e70f8ebe1e8349bdf49e4cbe5d8834Timo Sirainen the first one, we likely ended up overwriting the first mail when
0cb2e8eb55e70f8ebe1e8349bdf49e4cbe5d8834Timo Sirainen the second mail was moved over it.
0cb2e8eb55e70f8ebe1e8349bdf49e4cbe5d8834Timo Sirainen Nowadays everyone should be giving a bit more specific identifier,
0cb2e8eb55e70f8ebe1e8349bdf49e4cbe5d8834Timo Sirainen for example include microseconds in it which Dovecot does.
0cb2e8eb55e70f8ebe1e8349bdf49e4cbe5d8834Timo Sirainen There's a simple way to prevent this from happening in some cases:
0cb2e8eb55e70f8ebe1e8349bdf49e4cbe5d8834Timo Sirainen Don't move the mail from new/ to cur/ if it's mtime is >= time() -
0cb2e8eb55e70f8ebe1e8349bdf49e4cbe5d8834Timo Sirainen MAILDIR_SYNC_SECS. The second delivery's link() call then fails
0cb2e8eb55e70f8ebe1e8349bdf49e4cbe5d8834Timo Sirainen because the file is already in new/, and it will then use a
0cb2e8eb55e70f8ebe1e8349bdf49e4cbe5d8834Timo Sirainen different filename. There's a few problems with this however:
0cb2e8eb55e70f8ebe1e8349bdf49e4cbe5d8834Timo Sirainen - it requires extra stat() call which is unneeded extra I/O
0cb2e8eb55e70f8ebe1e8349bdf49e4cbe5d8834Timo Sirainen - another MUA might still move the mail to cur/
0cb2e8eb55e70f8ebe1e8349bdf49e4cbe5d8834Timo Sirainen - if first file's flags are modified by either Dovecot or another
0cb2e8eb55e70f8ebe1e8349bdf49e4cbe5d8834Timo Sirainen MUA, it's moved to cur/ (you _could_ just do the dirty-flagging
0cb2e8eb55e70f8ebe1e8349bdf49e4cbe5d8834Timo Sirainen but that'd be ugly)
0cb2e8eb55e70f8ebe1e8349bdf49e4cbe5d8834Timo Sirainen Because this is useful only for very few people and it requires
0cb2e8eb55e70f8ebe1e8349bdf49e4cbe5d8834Timo Sirainen extra I/O, I decided not to implement this. It should be however
0cb2e8eb55e70f8ebe1e8349bdf49e4cbe5d8834Timo Sirainen quite easy to do since we need to be able to deal with files in new/
0cb2e8eb55e70f8ebe1e8349bdf49e4cbe5d8834Timo Sirainen It's also possible to never accidentally overwrite a mail by using
0cb2e8eb55e70f8ebe1e8349bdf49e4cbe5d8834Timo Sirainen link() + unlink() rather than rename(). This however isn't very
0cb2e8eb55e70f8ebe1e8349bdf49e4cbe5d8834Timo Sirainen good idea as it introduces potential race conditions when multiple
0cb2e8eb55e70f8ebe1e8349bdf49e4cbe5d8834Timo Sirainen clients are accessing the mailbox:
0cb2e8eb55e70f8ebe1e8349bdf49e4cbe5d8834Timo Sirainen Trying to move the same mail from new/ to cur/ at the same time:
0cb2e8eb55e70f8ebe1e8349bdf49e4cbe5d8834Timo Sirainen a) Client 1 uses slightly different filename than client 2,
0cb2e8eb55e70f8ebe1e8349bdf49e4cbe5d8834Timo Sirainen for example one sets read-flag on but the other doesn't.
0cb2e8eb55e70f8ebe1e8349bdf49e4cbe5d8834Timo Sirainen You have the same mail duplicated now.
0cb2e8eb55e70f8ebe1e8349bdf49e4cbe5d8834Timo Sirainen b) Client 3 sees the mail between Client 1's and 2's link() calls
0cb2e8eb55e70f8ebe1e8349bdf49e4cbe5d8834Timo Sirainen and changes it's flag. You have the same mail duplicated now.
0cb2e8eb55e70f8ebe1e8349bdf49e4cbe5d8834Timo Sirainen And it gets worse when they're unlink()ing in cur/ directory:
0cb2e8eb55e70f8ebe1e8349bdf49e4cbe5d8834Timo Sirainen c) Client 1 changes mails's flag and client 2 changes it back
0cb2e8eb55e70f8ebe1e8349bdf49e4cbe5d8834Timo Sirainen between 1's link() and unlink(). The mail is now expunged.
0cb2e8eb55e70f8ebe1e8349bdf49e4cbe5d8834Timo Sirainen d) If you try to deal with the duplicates by unlink()ing another
0cb2e8eb55e70f8ebe1e8349bdf49e4cbe5d8834Timo Sirainen one of them, you might end up unlinking both of them.
0cb2e8eb55e70f8ebe1e8349bdf49e4cbe5d8834Timo Sirainen So, what should we do then if we notice a duplicate? First of all,
0cb2e8eb55e70f8ebe1e8349bdf49e4cbe5d8834Timo Sirainen it might not be a duplicate at all, readdir() might have just
0cb2e8eb55e70f8ebe1e8349bdf49e4cbe5d8834Timo Sirainen returned it twice because it was just renamed. What we should do is
0cb2e8eb55e70f8ebe1e8349bdf49e4cbe5d8834Timo Sirainen create a completely new base name for it and rename() it to that.
0cb2e8eb55e70f8ebe1e8349bdf49e4cbe5d8834Timo Sirainen If the call fails with ENOENT, it only means that it wasn't a
0cb2e8eb55e70f8ebe1e8349bdf49e4cbe5d8834Timo Sirainen duplicate after all.
0cb2e8eb55e70f8ebe1e8349bdf49e4cbe5d8834Timo Sirainen struct maildir_uidlist_sync_ctx *uidlist_sync_ctx;
0cb2e8eb55e70f8ebe1e8349bdf49e4cbe5d8834Timo Sirainenstatic int maildir_expunge(struct index_mailbox *ibox, const char *path,
0cb2e8eb55e70f8ebe1e8349bdf49e4cbe5d8834Timo Sirainenstatic int maildir_sync_flags(struct index_mailbox *ibox, const char *path,
0cb2e8eb55e70f8ebe1e8349bdf49e4cbe5d8834Timo Sirainen struct maildir_index_sync_context *ctx = context;
0cb2e8eb55e70f8ebe1e8349bdf49e4cbe5d8834Timo Sirainen (void)maildir_filename_get_flags(path, &flags, keywords);
0cb2e8eb55e70f8ebe1e8349bdf49e4cbe5d8834Timo Sirainen mail_index_sync_flags_apply(&ctx->sync_rec, &flags8, keywords);
0cb2e8eb55e70f8ebe1e8349bdf49e4cbe5d8834Timo Sirainen newpath = maildir_filename_set_flags(path, flags8, keywords);
0cb2e8eb55e70f8ebe1e8349bdf49e4cbe5d8834Timo Sirainen mail_index_update_flags(ctx->trans, ctx->seq, MODIFY_ADD,
0cb2e8eb55e70f8ebe1e8349bdf49e4cbe5d8834Timo Sirainenstatic int maildir_sync_record(struct index_mailbox *ibox,
0cb2e8eb55e70f8ebe1e8349bdf49e4cbe5d8834Timo Sirainen struct mail_index_sync_rec *sync_rec = &ctx->sync_rec;
0cb2e8eb55e70f8ebe1e8349bdf49e4cbe5d8834Timo Sirainen /* make it go through sequences to avoid looping through huge
0cb2e8eb55e70f8ebe1e8349bdf49e4cbe5d8834Timo Sirainen holes in UID range */
0cb2e8eb55e70f8ebe1e8349bdf49e4cbe5d8834Timo Sirainen if (mail_index_lookup_uid_range(view, sync_rec->uid1,
0cb2e8eb55e70f8ebe1e8349bdf49e4cbe5d8834Timo Sirainen if (mail_index_lookup_uid(view, seq, &uid) < 0)
0cb2e8eb55e70f8ebe1e8349bdf49e4cbe5d8834Timo Sirainen if (maildir_file_do(ibox, uid, maildir_expunge,
0cb2e8eb55e70f8ebe1e8349bdf49e4cbe5d8834Timo Sirainen if (mail_index_lookup_uid_range(view, sync_rec->uid1,
0cb2e8eb55e70f8ebe1e8349bdf49e4cbe5d8834Timo Sirainen for (ctx->seq = seq1; ctx->seq <= seq2; ctx->seq++) {
0cb2e8eb55e70f8ebe1e8349bdf49e4cbe5d8834Timo Sirainen if (mail_index_lookup_uid(view, ctx->seq, &uid) < 0)
0cb2e8eb55e70f8ebe1e8349bdf49e4cbe5d8834Timo Sirainen /* if this flag was dirty, drop it */
0cb2e8eb55e70f8ebe1e8349bdf49e4cbe5d8834Timo Sirainen if (mail_index_lookup(view, ctx->seq, &rec) < 0)
0cb2e8eb55e70f8ebe1e8349bdf49e4cbe5d8834Timo Sirainen if (rec->flags & MAIL_INDEX_MAIL_FLAG_DIRTY) {
0cb2e8eb55e70f8ebe1e8349bdf49e4cbe5d8834Timo Sirainenint maildir_sync_last_commit(struct index_mailbox *ibox)
0cb2e8eb55e70f8ebe1e8349bdf49e4cbe5d8834Timo Sirainen ret = mail_index_sync_begin(ibox->index, &ctx.sync_ctx, &ctx.view,
0cb2e8eb55e70f8ebe1e8349bdf49e4cbe5d8834Timo Sirainen if (mail_index_get_header(ctx.view, &hdr) == 0 &&
0cb2e8eb55e70f8ebe1e8349bdf49e4cbe5d8834Timo Sirainen (hdr->flags & MAIL_INDEX_HDR_FLAG_HAVE_DIRTY) != 0)
0cb2e8eb55e70f8ebe1e8349bdf49e4cbe5d8834Timo Sirainen ctx.trans = mail_index_transaction_begin(ctx.view, FALSE);
0cb2e8eb55e70f8ebe1e8349bdf49e4cbe5d8834Timo Sirainen while ((ret = mail_index_sync_next(ctx.sync_ctx,
0cb2e8eb55e70f8ebe1e8349bdf49e4cbe5d8834Timo Sirainen if (mail_index_transaction_commit(ctx.trans, &seq, &offset) < 0)
0cb2e8eb55e70f8ebe1e8349bdf49e4cbe5d8834Timo Sirainen if (mail_index_sync_end(ctx.sync_ctx, 0, 0) < 0)
0cb2e8eb55e70f8ebe1e8349bdf49e4cbe5d8834Timo Sirainenmaildir_sync_context_new(struct index_mailbox *ibox)
0cb2e8eb55e70f8ebe1e8349bdf49e4cbe5d8834Timo Sirainen ctx->new_dir = t_strconcat(ibox->path, "/new", NULL);
0cb2e8eb55e70f8ebe1e8349bdf49e4cbe5d8834Timo Sirainen ctx->cur_dir = t_strconcat(ibox->path, "/cur", NULL);
0cb2e8eb55e70f8ebe1e8349bdf49e4cbe5d8834Timo Sirainenstatic void maildir_sync_deinit(struct maildir_sync_context *ctx)
0cb2e8eb55e70f8ebe1e8349bdf49e4cbe5d8834Timo Sirainen (void)maildir_uidlist_sync_deinit(ctx->uidlist_sync_ctx);
0cb2e8eb55e70f8ebe1e8349bdf49e4cbe5d8834Timo Sirainenstatic int maildir_fix_duplicate(struct index_mailbox *ibox, const char *dir,
0cb2e8eb55e70f8ebe1e8349bdf49e4cbe5d8834Timo Sirainen old_path = t_strconcat(dir, "/", old_fname, NULL);
0cb2e8eb55e70f8ebe1e8349bdf49e4cbe5d8834Timo Sirainen new_fname = maildir_generate_tmp_filename(&ioloop_timeval);
0cb2e8eb55e70f8ebe1e8349bdf49e4cbe5d8834Timo Sirainen new_path = t_strconcat(ibox->path, "/new/", new_fname, NULL);
0cb2e8eb55e70f8ebe1e8349bdf49e4cbe5d8834Timo Sirainen "rename(%s, %s) failed: %m", old_path, new_path);
0cb2e8eb55e70f8ebe1e8349bdf49e4cbe5d8834Timo Sirainenstatic int maildir_scan_dir(struct maildir_sync_context *ctx, int new_dir)
0cb2e8eb55e70f8ebe1e8349bdf49e4cbe5d8834Timo Sirainen struct mail_storage *storage = ctx->ibox->box.storage;
0cb2e8eb55e70f8ebe1e8349bdf49e4cbe5d8834Timo Sirainen const char *dir;
0cb2e8eb55e70f8ebe1e8349bdf49e4cbe5d8834Timo Sirainen move_new = new_dir && !mailbox_is_readonly(&ctx->ibox->box) &&
0cb2e8eb55e70f8ebe1e8349bdf49e4cbe5d8834Timo Sirainen ret = maildir_uidlist_sync_next_pre(ctx->uidlist_sync_ctx,
0cb2e8eb55e70f8ebe1e8349bdf49e4cbe5d8834Timo Sirainen /* new file and we couldn't lock uidlist, check this
0cb2e8eb55e70f8ebe1e8349bdf49e4cbe5d8834Timo Sirainen later in next sync. */
0cb2e8eb55e70f8ebe1e8349bdf49e4cbe5d8834Timo Sirainen str_printfa(src, "%s/%s", ctx->new_dir, dp->d_name);
0cb2e8eb55e70f8ebe1e8349bdf49e4cbe5d8834Timo Sirainen str_printfa(dest, "%s/%s", ctx->cur_dir, dp->d_name);
0cb2e8eb55e70f8ebe1e8349bdf49e4cbe5d8834Timo Sirainen /* we moved it - it's \Recent for us */
0cb2e8eb55e70f8ebe1e8349bdf49e4cbe5d8834Timo Sirainen /* someone else moved it already */
} else if (new_dir) {
if (ret <= 0) {
if (ret < 0)
cur_mtime : 0;
const char *filename;
int ret;
seq = 0;
seq++;
goto __again;
const char *str;
t_push();
t_pop();
t_pop();
seq--;
INDEX_KEYWORDS_BYTE_COUNT) != 0) {
if (ret < 0)
else if (seq != 0) {
if (ret == 0) {
return ret;
if (cur_changed) {
return ret;
int ret;
return ret;
int ret;
return ret;
int ret;
if (ret < 0)