Mercurial > dovecot > original-hg > dovecot-1.2
changeset 1599:4c4d0d771350 HEAD
updates for syncing comments
author | Timo Sirainen <tss@iki.fi> |
---|---|
date | Sun, 06 Jul 2003 22:28:38 +0300 |
parents | d45c613e3b15 |
children | 993fe64a5e20 |
files | src/lib-index/maildir/maildir-sync.c |
diffstat | 1 files changed, 8 insertions(+), 8 deletions(-) [+] |
line wrap: on
line diff
--- a/src/lib-index/maildir/maildir-sync.c Sun Jul 06 03:29:00 2003 +0300 +++ b/src/lib-index/maildir/maildir-sync.c Sun Jul 06 22:28:38 2003 +0300 @@ -132,21 +132,19 @@ 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() - + Don't move the mail from new/ to cur/ if it's mtime (it's included + in beginning of file name, so stat() isn't needed) 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 but that'd be ugly) - 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/ - in any case. + Because this is useful only for very few people and it requires some + extra code, I decided not to implement it at least for now. It's also possible to never accidentally overwrite a mail by using link() + unlink() rather than rename(). This however isn't very @@ -164,8 +162,10 @@ 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. + c) Most other maildir clients use rename(). So if client 1 changes + mail's flag with link()+unlink() and client 2 using rename() + changes it back between 1's link() and unlink(), the mail gets + 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.