maildir-sync.c revision ead79af955bccc360de08c150918474c1809748e
3853N/A/* Copyright (C) 2004 Timo Sirainen */ 3853N/A Here's a description of how we handle Maildir synchronization and 3853N/A We want to be as efficient as we can. The most efficient way to 3853N/A check if changes have occured is to stat() the new/ and cur/ 6983N/A directories and uidlist file - if their mtimes haven't changed, 6983N/A there's no changes and we don't need to do anything. 3853N/A Problem 1: Multiple changes can happen within a single second - 3853N/A nothing guarantees that once we synced it, someone else didn't just 3853N/A then make a modification. Such modifications wouldn't get noticed 6983N/A until a new modification occured later. 6983N/A Problem 2: Syncing cur/ directory is much more costly than syncing 6983N/A new/. Moving mails from new/ to cur/ will always change mtime of 3853N/A cur/ causing us to sync it as well. 3853N/A Problem 3: We may not be able to move mail from new/ to cur/ 3853N/A because we're out of quota, or simply because we're accessing a 3853N/A Several checks below use MAILDIR_SYNC_SECS, which should be maximum 3853N/A clock drift between all computers accessing the maildir (eg. via 3853N/A NFS), rounded up to next second. Our default is 1 second, since 3853N/A everyone should be using NTP. 3853N/A Note that setting it to 0 works only if there's only one computer 3853N/A accessing the maildir. It's practically impossible to make two 3853N/A clocks _exactly_ synchronized. 3853N/A It might be possible to only use file server's clock by looking at 3853N/A the atime field, but I don't know how well that would actually work. 3853N/A We have dirty_cur_time variable which is set to cur/ directory's 3853N/A mtime when it's >= time() - MAILDIR_SYNC_SECS and we _think_ we have 3853N/A synchronized the directory. 3853N/A When dirty_cur_time is non-zero, we don't synchronize the cur/ 3853N/A b) opening a mail fails with ENOENT 3853N/A c) time() > dirty_cur_time + MAILDIR_SYNC_SECS 3853N/A This allows us to modify the maildir multiple times without having 3853N/A to sync it at every change. The sync will eventually be done to 3853N/A make sure we didn't miss any external changes. 3853N/A The dirty_cur_time is set when: 3853N/A - we move mail from new/ to cur/ 3853N/A - we sync cur/ directory and it's mtime is >= time() - MAILDIR_SYNC_SECS 3853N/A It's unset when we do the final syncing, ie. when mtime is 3853N/A older than time() - MAILDIR_SYNC_SECS. 3853N/A If new/'s mtime is >= time() - MAILDIR_SYNC_SECS, always synchronize 3853N/A it. dirty_cur_time-like feature might save us a few syncs, but 3853N/A that might break a client which saves a mail in one connection and 3853N/A tries to fetch it in another one. new/ directory is almost always 3853N/A empty, so syncing it should be very fast anyway. Actually this can still happen if we sync only new/ dir while another client is also moving mails from it to cur/ - it takes us a while to see them. That's pretty unlikely to happen however, and only way to fix it would be to always synchronize cur/ after new/. Normally we move all mails from new/ to cur/ whenever we sync it. If it's not possible for some reason, we mark the mail with "probably exists in new/ directory" flag. If rename() still fails because of ENOSPC or EDQUOT, we still save the flag changes in index with dirty-flag on. When moving the mail to cur/ directory, or when we notice it's already moved there, we apply the flag changes to the filename, rename it and remove the dirty flag. If there's dirty flags, this should be tried every time after expunge or when closing the mailbox. This file contains UID <-> filename mappings. It's updated only when new mail arrives, so it may contain filenames that have already been deleted. Updating is done by getting uidlist.lock file, writing the whole uidlist into it and rename()ing it over the old uidlist. This means there's no need to lock the file for reading. Whenever uidlist is rewritten, it's mtime must be larger than the old one's. Use utime() before rename() if needed. Note that inode checking wouldn't have been sufficient as inode numbers can be reused. This file is usually read the first time you need to know filename for given UID. After that it's not re-read unless new mails come that we Originally the middle identifier in Maildir filename was specified only as <process id>_<delivery counter>. That however created a problem with randomized PIDs which made it possible that the same PID was reused within one second. So if within one second a mail was delivered, MUA moved it to cur/ and another mail was delivered by a new process using same PID as the first one, we likely ended up overwriting the first mail when the second mail was moved over it. Nowadays everyone should be giving a bit more specific identifier, for example include microseconds in it which Dovecot does. There's a simple way to prevent this from happening in some cases: Don't move the mail from new/ to cur/ if it's mtime is >= time() - MAILDIR_SYNC_SECS. The second delivery's link() call then fails because the file is already in new/, and it will then use a different filename. There's a few problems with this however: - it requires extra stat() call which is unneeded extra I/O - another MUA might still move the mail to cur/ - if first file's flags are modified by either Dovecot or another MUA, it's moved to cur/ (you _could_ just do the dirty-flagging Because this is useful only for very few people and it requires extra I/O, I decided not to implement this. It should be however quite easy to do since we need to be able to deal with files in new/ It's also possible to never accidentally overwrite a mail by using link() + unlink() rather than rename(). This however isn't very good idea as it introduces potential race conditions when multiple clients are accessing the mailbox: Trying to move the same mail from new/ to cur/ at the same time: a) Client 1 uses slightly different filename than client 2, 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 "unlink(%s) failed: %m",
path);
"opendir(%s) failed: %m",
dir);
/* we moved it - it's \Recent for use */ /* someone else moved it already */ /* not enough disk space, leave here */ "rename(%s, %s) failed: %m",
/* possibly duplicate - try fixing it */ "closedir(%s) failed: %m",
dir);
/* first sync in this session, get cur stamp from index */ /* cur/ changed, or delayed cur/ check */ /* new UID in the middle of the mailbox - "Maildir sync: UID inserted in the middle " /* we haven't been able to update maildir with this record's flag changes. don't sync them. */ /* now, sync the index */