maildir-sync.c revision ba3d9eeb0bec6ed8465d68fa2480ad085559b580
285N/A/* Copyright (c) 2004-2008 Dovecot authors, see the included COPYING file */ 285N/A Here's a description of how we handle Maildir synchronization and 285N/A We want to be as efficient as we can. The most efficient way to 285N/A check if changes have occurred is to stat() the new/ and cur/ 285N/A directories and uidlist file - if their mtimes haven't changed, 285N/A there's no changes and we don't need to do anything. 285N/A Problem 1: Multiple changes can happen within a single second - 285N/A nothing guarantees that once we synced it, someone else didn't just 285N/A then make a modification. Such modifications wouldn't get noticed 285N/A until a new modification occurred later. 285N/A Problem 2: Syncing cur/ directory is much more costly than syncing 285N/A new/. Moving mails from new/ to cur/ will always change mtime of 285N/A cur/ causing us to sync it as well. 285N/A Problem 3: We may not be able to move mail from new/ to cur/ 285N/A because we're out of quota, or simply because we're accessing a 285N/A Several checks below use MAILDIR_SYNC_SECS, which should be maximum 285N/A clock drift between all computers accessing the maildir (eg. via 285N/A NFS), rounded up to next second. Our default is 1 second, since 285N/A everyone should be using NTP. 285N/A Note that setting it to 0 works only if there's only one computer 285N/A accessing the maildir. It's practically impossible to make two 285N/A clocks _exactly_ synchronized. 285N/A It might be possible to only use file server's clock by looking at 285N/A the atime field, but I don't know how well that would actually work. 285N/A We have dirty_cur_time variable which is set to cur/ directory's 285N/A mtime when it's >= time() - MAILDIR_SYNC_SECS and we _think_ we have 285N/A synchronized the directory. 285N/A When dirty_cur_time is non-zero, we don't synchronize the cur/ 285N/A a) cur/'s mtime changes 285N/A b) opening a mail fails with ENOENT 285N/A c) time() > dirty_cur_time + MAILDIR_SYNC_SECS 285N/A This allows us to modify the maildir multiple times without having 285N/A to sync it at every change. The sync will eventually be done to 285N/A make sure we didn't miss any external changes. 285N/A The dirty_cur_time is set when: 285N/A - we change message flags 285N/A - we move mail from new/ to cur/ 285N/A - we sync cur/ directory and it's mtime is >= time() - MAILDIR_SYNC_SECS 285N/A It's unset when we do the final syncing, ie. when mtime is 285N/A older than time() - MAILDIR_SYNC_SECS. 285N/A If new/'s mtime is >= time() - MAILDIR_SYNC_SECS, always synchronize 285N/A it. dirty_cur_time-like feature might save us a few syncs, but 285N/A that might break a client which saves a mail in one connection and 285N/A tries to fetch it in another one. new/ directory is almost always 285N/A empty, so syncing it should be very fast anyway. Actually this can 285N/A still happen if we sync only new/ dir while another client is also 285N/A moving mails from it to cur/ - it takes us a while to see them. 285N/A That's pretty unlikely to happen however, and only way to fix it 285N/A would be to always synchronize cur/ after new/. 285N/A Normally we move all mails from new/ to cur/ whenever we sync it. If 285N/A it's not possible for some reason, we mark the mail with "probably 285N/A exists in new/ directory" flag. 285N/A If rename() still fails because of ENOSPC or EDQUOT, we still save 285N/A the flag changes in index with dirty-flag on. When moving the mail 285N/A to cur/ directory, or when we notice it's already moved there, we 285N/A apply the flag changes to the filename, rename it and remove the 285N/A dirty flag. If there's dirty flags, this should be tried every time 285N/A after expunge or when closing the mailbox. 285N/A This file contains UID <-> filename mappings. It's updated only when 285N/A new mail arrives, so it may contain filenames that have already been 285N/A deleted. Updating is done by getting uidlist.lock file, writing the 285N/A whole uidlist into it and rename()ing it over the old uidlist. This 285N/A means there's no need to lock the file for reading. 285N/A Whenever uidlist is rewritten, it's mtime must be larger than the old 285N/A one's. Use utime() before rename() if needed. Note that inode checking 285N/A wouldn't have been sufficient as inode numbers can be reused. 285N/A This file is usually read the first time you need to know filename for 285N/A given UID. After that it's not re-read unless new mails come that we 285N/A Originally the middle identifier in Maildir filename was specified 285N/A only as <process id>_<delivery counter>. That however created a 285N/A problem with randomized PIDs which made it possible that the same 285N/A PID was reused within one second. 285N/A So if within one second a mail was delivered, MUA moved it to cur/ 285N/A and another mail was delivered by a new process using same PID as 285N/A the first one, we likely ended up overwriting the first mail when 285N/A the second mail was moved over it. 285N/A Nowadays everyone should be giving a bit more specific identifier, 285N/A for example include microseconds in it which Dovecot does. 285N/A There's a simple way to prevent this from happening in some cases: 285N/A Don't move the mail from new/ to cur/ if it's mtime is >= time() - 285N/A MAILDIR_SYNC_SECS. The second delivery's link() call then fails 285N/A because the file is already in new/, and it will then use a 285N/A different filename. There's a few problems with this however: 285N/A - it requires extra stat() call which is unneeded extra I/O 285N/A - another MUA might still move the mail to cur/ 285N/A - if first file's flags are modified by either Dovecot or another 285N/A MUA, it's moved to cur/ (you _could_ just do the dirty-flagging 285N/A Because this is useful only for very few people and it requires 285N/A extra I/O, I decided not to implement this. It should be however 285N/A quite easy to do since we need to be able to deal with files in new/ 285N/A It's also possible to never accidentally overwrite a mail by using 285N/A link() + unlink() rather than rename(). This however isn't very 285N/A good idea as it introduces potential race conditions when multiple 285N/A clients are accessing the mailbox: 285N/A Trying to move the same mail from new/ to cur/ at the same time: 285N/A a) Client 1 uses slightly different filename than client 2, 285N/A for example one sets read-flag on but the other doesn't. You have the same mail duplicated now. b) Client 3 sees the mail between Client 1's and 2's link() calls and changes it's flag. You have the same mail duplicated now. And it gets worse when they're unlink()ing in cur/ directory: c) Client 1 changes mails's flag and client 2 changes it back between 1's link() and unlink(). The mail is now expunged. d) If you try to deal with the duplicates by unlink()ing another one of them, you might end up unlinking both of them. So, what should we do then if we notice a duplicate? First of all, it might not be a duplicate at all, readdir() might have just returned it twice because it was just renamed. What we should do is create a completely new base name for it and rename() it to that. If the call fails with ENOENT, it only means that it wasn't a /* When rename()ing many files from new/ to cur/, it's possible that next readdir() skips some files. we don't of course wish to lose them, so we go and rescan the new/ directory again from beginning until no files are left. This value is just an optimization to avoid checking the directory twice unneededly. usually only NFS is the problem case. 1 is the safest bet here, but I guess 5 will do just fine too. */ /* This is mostly to avoid infinite looping when rename() destination already exists as the hard link of the file itself. */ /* most likely the files just don't exist anymore. don't really care about other errors much. */ /* Files are the same. this means either a race condition between stat() calls, or that the files were link()ed. */ /* The file has hard links and it hasn't had any changes (such as renames) for a while, so this rename()ing one file on top of the other would fix this safely, except POSIX decided that rename() doesn't work that way. So we'll have unlink() one and hope that another process didn't just decide to unlink() the other (uidlist lock prevents this from "unlink(%s) failed: %m",
path2);
"Couldn't fix a duplicate: rename(%s, %s) failed: %m",
"stat(%s) failed: %m",
path);
"opendir(%s) failed: %m",
path);
"fstat(%s) failed: %m",
path);
/* we moved it - it's \Recent for us */ /* someone else moved it already */ /* not enough disk space / read-only maildir, "rename(%s, %s) failed: %m",
/* possibly duplicate - try fixing it */ "readdir(%s) failed: %m",
path);
"closedir(%s) failed: %m",
path);
/* try to avoid stat()ing by first checking delayed changes */ /* refresh index and try again */ /* refresh index and try again */ /* make sure uidlist's next_uid is at least as large as index file's. typically this happens only if uidlist gets /* if there are files in new/, we'll need to move them. we'll check this by checking if we have any recent messages */ Locking, locking, locking.. Wasn't maildir supposed to be lockless? We can get here either as beginning a real maildir sync, or when committing changes to maildir but a file was lost (maybe renamed). So, we're going to need two locks. One for index and one for uidlist. To avoid deadlocking do the uidlist lock always first. uidlist is needed only for figuring out UIDs for newly seen files, so theoretically we wouldn't need to lock it unless there are new files. It has a few problems though, assuming the index lock didn't already protect it (eg. in-memory indexes): 1. Just because you see a new file which doesn't exist in uidlist file, doesn't mean that the file really exists anymore, or that your readdir() lists all new files. Meaning that this is possible: A: opendir(), readdir() -> new file ... -- new files are written to the maildir -- B: opendir(), readdir() -> new file, lock uidlist, readdir() -> another new file, rewrite uidlist, unlock A: ... lock uidlist, readdir() -> nothing left, rewrite uidlist, The second time running A didn't see the two new files. To handle this correctly, it must not remove the new unseen files from uidlist. This is possible to do, but adds extra complexity. 2. If another process is rename()ing files while we are readdir()ing, it's possible that readdir() never lists some files, causing Dovecot to assume they were expunged. In next sync they would show up again, but client could have already been notified of that and they would show up under new UIDs, so the damage is Both of the problems can be avoided if we simply lock the uidlist before syncing and keep it until sync is finished. Typically this would happen in any case, as there is the index lock.. The second case is still a problem with external changes though, because maildir doesn't require any kind of locking. Luckily this problem rarely happens except under high amount of modifications. /* locking failed. sync anyway without locking so that it's possible to expunge messages when out of quota. */ /* we're already forcing a sync, we're trying to find a message that was probably already expunged, don't loop for a long time trying to find it. */ "Internal mailbox synchronization failure, " "showing only old mails.",
/* if we're going to check cur/ dir our current logic requires that new/ dir is checked as well. it's a good idea anyway. */ /* rename()d at least some files, which might have caused some other files to be missed. check again (see MAILDIR_RENAME_RESCAN_COUNT). */ /* finish uidlist syncing, but keep it still locked */ /* make sure we sync the maildir later */ /* NOTE: index syncing here might cause a re-sync due to files getting lost, so this function might be called /* we didn't find it, possibly expunged? */ /* maybe it's expunged. check again. */ /* lost some files from new/, see if thery're in cur/ */