maildir-sync.c revision 43955c82f9f52c969c777b3da00bc170183dfdf2
2454dfa32c93c20a8522c6ed42fe057baaac9f9aStephan Bosch/* Copyright (c) 2004-2010 Dovecot authors, see the included COPYING file */
ae9691f7ef36d5272d72c90fa51393dfea5dd126Timo Sirainen Here's a description of how we handle Maildir synchronization and
ae9691f7ef36d5272d72c90fa51393dfea5dd126Timo Sirainen it's problems:
ae9691f7ef36d5272d72c90fa51393dfea5dd126Timo Sirainen We want to be as efficient as we can. The most efficient way to
2eccb2637d0153bb7f9ad39a70f254cece74342cTimo Sirainen check if changes have occurred is to stat() the new/ and cur/
2eccb2637d0153bb7f9ad39a70f254cece74342cTimo Sirainen directories and uidlist file - if their mtimes haven't changed,
7877db7b5daad125b6cb3e015574f33871c9a51bTimo Sirainen there's no changes and we don't need to do anything.
ae9691f7ef36d5272d72c90fa51393dfea5dd126Timo Sirainen Problem 1: Multiple changes can happen within a single second -
ae9691f7ef36d5272d72c90fa51393dfea5dd126Timo Sirainen nothing guarantees that once we synced it, someone else didn't just
ae9691f7ef36d5272d72c90fa51393dfea5dd126Timo Sirainen then make a modification. Such modifications wouldn't get noticed
ae9691f7ef36d5272d72c90fa51393dfea5dd126Timo Sirainen until a new modification occurred later.
2eccb2637d0153bb7f9ad39a70f254cece74342cTimo Sirainen Problem 2: Syncing cur/ directory is much more costly than syncing
86bdb644d147a73df85abce4325254d694217a5fTimo Sirainen new/. Moving mails from new/ to cur/ will always change mtime of
ae9691f7ef36d5272d72c90fa51393dfea5dd126Timo Sirainen cur/ causing us to sync it as well.
ae9691f7ef36d5272d72c90fa51393dfea5dd126Timo Sirainen Problem 3: We may not be able to move mail from new/ to cur/
ae9691f7ef36d5272d72c90fa51393dfea5dd126Timo Sirainen because we're out of quota, or simply because we're accessing a
ae9691f7ef36d5272d72c90fa51393dfea5dd126Timo Sirainen read-only mailbox.
ae9691f7ef36d5272d72c90fa51393dfea5dd126Timo Sirainen MAILDIR_SYNC_SECS
ae9691f7ef36d5272d72c90fa51393dfea5dd126Timo Sirainen -----------------
a01faca549a403b2eda938cea0b1fb76c3ff44b6Aki Tuomi Several checks below use MAILDIR_SYNC_SECS, which should be maximum
a01faca549a403b2eda938cea0b1fb76c3ff44b6Aki Tuomi clock drift between all computers accessing the maildir (eg. via
86bdb644d147a73df85abce4325254d694217a5fTimo Sirainen NFS), rounded up to next second. Our default is 1 second, since
a01faca549a403b2eda938cea0b1fb76c3ff44b6Aki Tuomi everyone should be using NTP.
ae9691f7ef36d5272d72c90fa51393dfea5dd126Timo Sirainen Note that setting it to 0 works only if there's only one computer
ae9691f7ef36d5272d72c90fa51393dfea5dd126Timo Sirainen accessing the maildir. It's practically impossible to make two
b7324e421e2132cbbf753e6fdbe675bbaecdf929Timo Sirainen clocks _exactly_ synchronized.
ae9691f7ef36d5272d72c90fa51393dfea5dd126Timo Sirainen It might be possible to only use file server's clock by looking at
ae9691f7ef36d5272d72c90fa51393dfea5dd126Timo Sirainen the atime field, but I don't know how well that would actually work.
ae9691f7ef36d5272d72c90fa51393dfea5dd126Timo Sirainen cur directory
ae9691f7ef36d5272d72c90fa51393dfea5dd126Timo Sirainen -------------
ae9691f7ef36d5272d72c90fa51393dfea5dd126Timo Sirainen We have dirty_cur_time variable which is set to cur/ directory's
ae9691f7ef36d5272d72c90fa51393dfea5dd126Timo Sirainen mtime when it's >= time() - MAILDIR_SYNC_SECS and we _think_ we have
ae9691f7ef36d5272d72c90fa51393dfea5dd126Timo Sirainen synchronized the directory.
2eccb2637d0153bb7f9ad39a70f254cece74342cTimo Sirainen When dirty_cur_time is non-zero, we don't synchronize the cur/
2eccb2637d0153bb7f9ad39a70f254cece74342cTimo Sirainen directory until
2eccb2637d0153bb7f9ad39a70f254cece74342cTimo Sirainen a) cur/'s mtime changes
ae9691f7ef36d5272d72c90fa51393dfea5dd126Timo Sirainen b) opening a mail fails with ENOENT
ae9691f7ef36d5272d72c90fa51393dfea5dd126Timo Sirainen c) time() > dirty_cur_time + MAILDIR_SYNC_SECS
ae9691f7ef36d5272d72c90fa51393dfea5dd126Timo Sirainen This allows us to modify the maildir multiple times without having
ae9691f7ef36d5272d72c90fa51393dfea5dd126Timo Sirainen to sync it at every change. The sync will eventually be done to
ae9691f7ef36d5272d72c90fa51393dfea5dd126Timo Sirainen make sure we didn't miss any external changes.
ae9691f7ef36d5272d72c90fa51393dfea5dd126Timo Sirainen The dirty_cur_time is set when:
ae9691f7ef36d5272d72c90fa51393dfea5dd126Timo Sirainen - we change message flags
ae9691f7ef36d5272d72c90fa51393dfea5dd126Timo Sirainen - we expunge messages
ae9691f7ef36d5272d72c90fa51393dfea5dd126Timo Sirainen - we move mail from new/ to cur/
ae9691f7ef36d5272d72c90fa51393dfea5dd126Timo Sirainen - we sync cur/ directory and it's mtime is >= time() - MAILDIR_SYNC_SECS
ae9691f7ef36d5272d72c90fa51393dfea5dd126Timo Sirainen It's unset when we do the final syncing, ie. when mtime is
ae9691f7ef36d5272d72c90fa51393dfea5dd126Timo Sirainen older than time() - MAILDIR_SYNC_SECS.
ae9691f7ef36d5272d72c90fa51393dfea5dd126Timo Sirainen new directory
4e8e7a93628b4ed60aaaa47c6f72c1433f21e81dTimo Sirainen -------------
a01faca549a403b2eda938cea0b1fb76c3ff44b6Aki Tuomi If new/'s mtime is >= time() - MAILDIR_SYNC_SECS, always synchronize
7877db7b5daad125b6cb3e015574f33871c9a51bTimo Sirainen it. dirty_cur_time-like feature might save us a few syncs, but
a01faca549a403b2eda938cea0b1fb76c3ff44b6Aki Tuomi that might break a client which saves a mail in one connection and
86bdb644d147a73df85abce4325254d694217a5fTimo Sirainen tries to fetch it in another one. new/ directory is almost always
86bdb644d147a73df85abce4325254d694217a5fTimo Sirainen empty, so syncing it should be very fast anyway. Actually this can
86bdb644d147a73df85abce4325254d694217a5fTimo Sirainen still happen if we sync only new/ dir while another client is also
86bdb644d147a73df85abce4325254d694217a5fTimo Sirainen moving mails from it to cur/ - it takes us a while to see them.
86bdb644d147a73df85abce4325254d694217a5fTimo Sirainen That's pretty unlikely to happen however, and only way to fix it
86bdb644d147a73df85abce4325254d694217a5fTimo Sirainen would be to always synchronize cur/ after new/.
86bdb644d147a73df85abce4325254d694217a5fTimo Sirainen Normally we move all mails from new/ to cur/ whenever we sync it. If
86bdb644d147a73df85abce4325254d694217a5fTimo Sirainen it's not possible for some reason, we mark the mail with "probably
86bdb644d147a73df85abce4325254d694217a5fTimo Sirainen exists in new/ directory" flag.
86bdb644d147a73df85abce4325254d694217a5fTimo Sirainen If rename() still fails because of ENOSPC or EDQUOT, we still save
86bdb644d147a73df85abce4325254d694217a5fTimo Sirainen the flag changes in index with dirty-flag on. When moving the mail
86bdb644d147a73df85abce4325254d694217a5fTimo Sirainen to cur/ directory, or when we notice it's already moved there, we
86bdb644d147a73df85abce4325254d694217a5fTimo Sirainen apply the flag changes to the filename, rename it and remove the
a01faca549a403b2eda938cea0b1fb76c3ff44b6Aki Tuomi dirty flag. If there's dirty flags, this should be tried every time
a01faca549a403b2eda938cea0b1fb76c3ff44b6Aki Tuomi after expunge or when closing the mailbox.
7877db7b5daad125b6cb3e015574f33871c9a51bTimo Sirainen This file contains UID <-> filename mappings. It's updated only when
7877db7b5daad125b6cb3e015574f33871c9a51bTimo Sirainen new mail arrives, so it may contain filenames that have already been
7877db7b5daad125b6cb3e015574f33871c9a51bTimo Sirainen deleted. Updating is done by getting uidlist.lock file, writing the
7877db7b5daad125b6cb3e015574f33871c9a51bTimo Sirainen whole uidlist into it and rename()ing it over the old uidlist. This
7877db7b5daad125b6cb3e015574f33871c9a51bTimo Sirainen means there's no need to lock the file for reading.
7877db7b5daad125b6cb3e015574f33871c9a51bTimo Sirainen Whenever uidlist is rewritten, it's mtime must be larger than the old
7877db7b5daad125b6cb3e015574f33871c9a51bTimo Sirainen one's. Use utime() before rename() if needed. Note that inode checking
7877db7b5daad125b6cb3e015574f33871c9a51bTimo Sirainen wouldn't have been sufficient as inode numbers can be reused.
7877db7b5daad125b6cb3e015574f33871c9a51bTimo Sirainen This file is usually read the first time you need to know filename for
7877db7b5daad125b6cb3e015574f33871c9a51bTimo Sirainen given UID. After that it's not re-read unless new mails come that we
7877db7b5daad125b6cb3e015574f33871c9a51bTimo Sirainen don't know about.
7877db7b5daad125b6cb3e015574f33871c9a51bTimo Sirainen broken clients
7877db7b5daad125b6cb3e015574f33871c9a51bTimo Sirainen --------------
7877db7b5daad125b6cb3e015574f33871c9a51bTimo Sirainen Originally the middle identifier in Maildir filename was specified
7877db7b5daad125b6cb3e015574f33871c9a51bTimo Sirainen only as <process id>_<delivery counter>. That however created a
ae9691f7ef36d5272d72c90fa51393dfea5dd126Timo Sirainen problem with randomized PIDs which made it possible that the same
ae9691f7ef36d5272d72c90fa51393dfea5dd126Timo Sirainen PID was reused within one second.
7877db7b5daad125b6cb3e015574f33871c9a51bTimo Sirainen So if within one second a mail was delivered, MUA moved it to cur/
ae9691f7ef36d5272d72c90fa51393dfea5dd126Timo Sirainen and another mail was delivered by a new process using same PID as
ae9691f7ef36d5272d72c90fa51393dfea5dd126Timo Sirainen the first one, we likely ended up overwriting the first mail when
ae9691f7ef36d5272d72c90fa51393dfea5dd126Timo Sirainen the second mail was moved over it.
ae9691f7ef36d5272d72c90fa51393dfea5dd126Timo Sirainen Nowadays everyone should be giving a bit more specific identifier,
7877db7b5daad125b6cb3e015574f33871c9a51bTimo Sirainen for example include microseconds in it which Dovecot does.
ae9691f7ef36d5272d72c90fa51393dfea5dd126Timo Sirainen There's a simple way to prevent this from happening in some cases:
ae9691f7ef36d5272d72c90fa51393dfea5dd126Timo Sirainen Don't move the mail from new/ to cur/ if it's mtime is >= time() -
ae9691f7ef36d5272d72c90fa51393dfea5dd126Timo Sirainen MAILDIR_SYNC_SECS. The second delivery's link() call then fails
ae9691f7ef36d5272d72c90fa51393dfea5dd126Timo Sirainen because the file is already in new/, and it will then use a
ae9691f7ef36d5272d72c90fa51393dfea5dd126Timo Sirainen different filename. There's a few problems with this however:
ae9691f7ef36d5272d72c90fa51393dfea5dd126Timo Sirainen - it requires extra stat() call which is unneeded extra I/O
7877db7b5daad125b6cb3e015574f33871c9a51bTimo Sirainen - another MUA might still move the mail to cur/
791fb70b3255a11a91ce0c2dc3ae1460d4cf8459Timo Sirainen - if first file's flags are modified by either Dovecot or another
a18e2525cb076066784967d6c8118a01dd38ac6bTimo Sirainen MUA, it's moved to cur/ (you _could_ just do the dirty-flagging
a18e2525cb076066784967d6c8118a01dd38ac6bTimo Sirainen but that'd be ugly)
2eccb2637d0153bb7f9ad39a70f254cece74342cTimo Sirainen Because this is useful only for very few people and it requires
2eccb2637d0153bb7f9ad39a70f254cece74342cTimo Sirainen extra I/O, I decided not to implement this. It should be however
a18e2525cb076066784967d6c8118a01dd38ac6bTimo Sirainen quite easy to do since we need to be able to deal with files in new/
2eccb2637d0153bb7f9ad39a70f254cece74342cTimo Sirainen It's also possible to never accidentally overwrite a mail by using
7877db7b5daad125b6cb3e015574f33871c9a51bTimo Sirainen link() + unlink() rather than rename(). This however isn't very
7877db7b5daad125b6cb3e015574f33871c9a51bTimo Sirainen good idea as it introduces potential race conditions when multiple
202b4674243a4a4826c35ed4d089831985c47256Timo Sirainen clients are accessing the mailbox:
7877db7b5daad125b6cb3e015574f33871c9a51bTimo Sirainen Trying to move the same mail from new/ to cur/ at the same time:
7877db7b5daad125b6cb3e015574f33871c9a51bTimo Sirainen a) Client 1 uses slightly different filename than client 2,
7877db7b5daad125b6cb3e015574f33871c9a51bTimo Sirainen for example one sets read-flag on but the other doesn't.
7877db7b5daad125b6cb3e015574f33871c9a51bTimo Sirainen You have the same mail duplicated now.
95f5b08fa73ddd9a9de40a97aa141e9c74e0645eAki Tuomi b) Client 3 sees the mail between Client 1's and 2's link() calls
95f5b08fa73ddd9a9de40a97aa141e9c74e0645eAki Tuomi and changes it's flag. You have the same mail duplicated now.
ae9691f7ef36d5272d72c90fa51393dfea5dd126Timo Sirainen And it gets worse when they're unlink()ing in cur/ directory:
95f5b08fa73ddd9a9de40a97aa141e9c74e0645eAki Tuomi c) Client 1 changes mails's flag and client 2 changes it back
ae9691f7ef36d5272d72c90fa51393dfea5dd126Timo Sirainen between 1's link() and unlink(). The mail is now expunged.
ae9691f7ef36d5272d72c90fa51393dfea5dd126Timo Sirainen d) If you try to deal with the duplicates by unlink()ing another
ae9691f7ef36d5272d72c90fa51393dfea5dd126Timo Sirainen one of them, you might end up unlinking both of them.
ae9691f7ef36d5272d72c90fa51393dfea5dd126Timo Sirainen So, what should we do then if we notice a duplicate? First of all,
ae9691f7ef36d5272d72c90fa51393dfea5dd126Timo Sirainen it might not be a duplicate at all, readdir() might have just
ae9691f7ef36d5272d72c90fa51393dfea5dd126Timo Sirainen returned it twice because it was just renamed. What we should do is
ae9691f7ef36d5272d72c90fa51393dfea5dd126Timo Sirainen create a completely new base name for it and rename() it to that.
ae9691f7ef36d5272d72c90fa51393dfea5dd126Timo Sirainen If the call fails with ENOENT, it only means that it wasn't a
f6497ac81e6de57870936d538acccb75ce408fc1Timo Sirainen duplicate after all.
f6497ac81e6de57870936d538acccb75ce408fc1Timo Sirainen/* When rename()ing many files from new/ to cur/, it's possible that next
f6497ac81e6de57870936d538acccb75ce408fc1Timo Sirainen readdir() skips some files. we don't of course wish to lose them, so we
f6497ac81e6de57870936d538acccb75ce408fc1Timo Sirainen go and rescan the new/ directory again from beginning until no files are
f6ae9ae80a1fcf6c8f45ab759f0074caaa66c9c8Timo Sirainen left. This value is just an optimization to avoid checking the directory
f6ae9ae80a1fcf6c8f45ab759f0074caaa66c9c8Timo Sirainen twice unneededly. usually only NFS is the problem case. 1 is the safest
736b1800b0409ba7443d33ecb8d0fb9f8b091660Timo Sirainen bet here, but I guess 5 will do just fine too. */
736b1800b0409ba7443d33ecb8d0fb9f8b091660Timo Sirainen/* This is mostly to avoid infinite looping when rename() destination already
736b1800b0409ba7443d33ecb8d0fb9f8b091660Timo Sirainen exists as the hard link of the file itself. */
736b1800b0409ba7443d33ecb8d0fb9f8b091660Timo Sirainen struct maildir_uidlist_sync_ctx *uidlist_sync_ctx;
f6ae9ae80a1fcf6c8f45ab759f0074caaa66c9c8Timo Sirainen struct maildir_index_sync_context *index_sync_ctx;
a18503d5dc0751a1f9785e48438a219d95c0b9c2Timo Sirainenvoid maildir_sync_notify(struct maildir_sync_context *ctx)
a18503d5dc0751a1f9785e48438a219d95c0b9c2Timo Sirainen /* we got here from maildir-save.c. it has no
a18503d5dc0751a1f9785e48438a219d95c0b9c2Timo Sirainen maildir_sync_context, */
f6ae9ae80a1fcf6c8f45ab759f0074caaa66c9c8Timo Sirainen if (now - ctx->last_touch > MAILDIR_LOCK_TOUCH_SECS && ctx->locked) {
f6ae9ae80a1fcf6c8f45ab759f0074caaa66c9c8Timo Sirainen (void)maildir_uidlist_lock_touch(ctx->mbox->uidlist);
f6ae9ae80a1fcf6c8f45ab759f0074caaa66c9c8Timo Sirainen if (now - ctx->last_notify > MAIL_STORAGE_STAYALIVE_SECS) {
736b1800b0409ba7443d33ecb8d0fb9f8b091660Timo Sirainen if (box->storage->callbacks.notify_ok != NULL) {
736b1800b0409ba7443d33ecb8d0fb9f8b091660Timo Sirainenmaildir_sync_context_new(struct maildir_mailbox *mbox,
736b1800b0409ba7443d33ecb8d0fb9f8b091660Timo Sirainen ctx->new_dir = t_strconcat(mbox->box.path, "/new", NULL);
736b1800b0409ba7443d33ecb8d0fb9f8b091660Timo Sirainen ctx->cur_dir = t_strconcat(mbox->box.path, "/cur", NULL);
10972f2a15f5538860fcc1d4adda227d59d2d757Timo Sirainenstatic void maildir_sync_deinit(struct maildir_sync_context *ctx)
10972f2a15f5538860fcc1d4adda227d59d2d757Timo Sirainen (void)maildir_uidlist_sync_deinit(&ctx->uidlist_sync_ctx, FALSE);
10972f2a15f5538860fcc1d4adda227d59d2d757Timo Sirainen maildir_sync_index_rollback(&ctx->index_sync_ctx);
bb869cc24b24a8df84a43154c628785d6aee784cTimo Sirainenstatic int maildir_fix_duplicate(struct maildir_sync_context *ctx,
bb869cc24b24a8df84a43154c628785d6aee784cTimo Sirainen fname1 = maildir_uidlist_sync_get_full_filename(ctx->uidlist_sync_ctx,
4e8e7a93628b4ed60aaaa47c6f72c1433f21e81dTimo Sirainen if (stat(path1, &st1) < 0 || stat(path2, &st2) < 0) {
7877db7b5daad125b6cb3e015574f33871c9a51bTimo Sirainen /* most likely the files just don't exist anymore.
f6497ac81e6de57870936d538acccb75ce408fc1Timo Sirainen don't really care about other errors much. */
ae9691f7ef36d5272d72c90fa51393dfea5dd126Timo Sirainen /* Files are the same. this means either a race condition
const char *path;
#ifdef HAVE_DIRFD
if (new_dir) {
errno = 0;
flags = 0;
if (move_new) {
move_count++;
move_count++;
} else if (new_dir) {
if (ret <= 0) {
if (ret < 0)
T_BEGIN {
} T_END;
if (ret < 0)
#ifdef __APPLE__
if (errno != 0) {
if (dir_changed) {
const void *data;
if (data_size == 0) {
(undirty || \
if (!*new_changed_r) {
if (!*cur_changed_r) {
if (check_new)
if (check_cur)
} else if (*new_changed_r) {
const char *fname;
int ret;
if (forced)
if (ret <= 0)
return ret;
if (!cur_changed) {
sync_flags = 0;
if (forced)
if (ret <= 0) {
if (ret == 0) {
if (forced) {
if (ret <= 0) {
unsigned int count = 0;
if (ret < 0)
if (cur_changed) {
if (ret < 0)
if (ret < 0)
if (ret == 0)
if (ret < 0)
if (ret == 0) {
*find_uid = 0;
*find_uid = 0;
bool lost_files;
int ret;
T_BEGIN {
} T_END;
if (uid != 0) {
T_BEGIN {
&lost_files);
} T_END;
return ret;
struct mailbox_sync_context *
int ret = 0;
T_BEGIN {
&lost_files);
} T_END;
if (lost_files) {
int ret;
T_BEGIN {
} T_END;