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