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.