[Dovecot] index synchronization during local delivery

[Andy YB Hu]

Tried it, found it could trigger NFS issue.

The test is on one machine runs the script to lock the dovecot-uidlist,
moving mail into cur/new, append one line to dovecot-uidlist, and unlock
it.  On another different machine, run one script to SELECT, another script
to COPY. Found the similar issue in
http://dovecot.org/pipermail/dovecot/2012-February/063539.html

Whether it means the dovecot LDA also needs to run on the same server with
the backend server?


                                                                           
             Timo Sirainen                                                 
             <tss at iki.fi>                                                  
             Sent by:                                                   To 
             dovecot-bounces at d         Dovecot Mailing List                
             ovecot.org                <dovecot at dovecot.org>               
                                                                        cc 
                                                                           
             02/15/2012 12:25                                      Subject 
             PM                        Re: [Dovecot] index synchronization 
                                       during local delivery               
                                                                           
             Please respond to                                             
              Dovecot Mailing                                              
                   List                                                    
             <dovecot at dovecot.                                             
                   org>                                                    
                                                                           
                                                                           




On 15.2.2012, at 6.13, Andy YB Hu wrote:

> I can generate the UID once I create the uidlist lock, and the UID is
> incremental globally.
>
> Some questions:
> 1, Whether I can  write the mail to tmp/ after creating
> dovecot-uidlist.lock?

Yes, then you'll just keep the lock longer than necessary.

> 2, I did the 5 steps manually, found that new mail is set to OLD flag, so
> that when SELECT command, it told there was no NEW mail.  Looks like need
> to change code in maildir_uidlist_sync_next_uid()?

I guess that means that the mail didn't get a \Recent flag. Wht Dovecot
version is this? Are you saving the mail to new/?

> 3, About the dovecot-uidlist.lock file creation and deletion, I checked
the
> code, there are functions in dovecot like maildir_uidlist_lock_timeout
and
> maildir_uidlist_unlock. If I did that via calling these functions, there
> are lots of extra codes need to call(like auth, mailbox open...).

Yes, way too much work to do that way.

> So the
> question is if I do that in my codes, how to handle the race condition
> correctly? (At least there would be other sessions want to lock the files
> also / already locked it while I want to create the dovecot-uidlist.lock)

It's a typical dotlock file. You can create it with either open(.., O_EXCL)
or creating a temp file and trying to link() it to the .lock file. Or you
can also directly call the file_dotlock_create() in src/lib/file-dotlock.h
-------------- next part --------------
A non-text attachment was scrubbed...
Name: graycol.gif
Type: image/gif
Size: 105 bytes
Desc: not available
URL: <http://dovecot.org/pipermail/dovecot/attachments/20120216/39bf081b/attachment.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pic09186.gif
Type: image/gif
Size: 1255 bytes
Desc: not available
URL: <http://dovecot.org/pipermail/dovecot/attachments/20120216/39bf081b/attachment-0001.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ecblank.gif
Type: image/gif
Size: 45 bytes
Desc: not available
URL: <http://dovecot.org/pipermail/dovecot/attachments/20120216/39bf081b/attachment-0002.gif>