sync_client bails out after 3 MAILBOXES need upgrading to USER in one run

Wesley Craig wes at umich.edu
Tue Sep 12 10:25:57 EDT 2006


On 29 Aug 2006, at 11:39, Ken Murchison wrote:
> The main reason things changed is sypport for shared mailboxes.  I  
> can't   elaborate now because I'm driving.

Can you say more about this?  I'd like to fix this code and resubmit  
it.  The current implementation causes sync_client to bail out,  
particularly during xfer.

On a related note, what was the problem with accepting the Cambridge  
patches for delayed folder deletion?  I'm interested in working on  
getting that or similar code accepted.  Now that we have delayed  
expunge for messages, we continue to run tape backups only for the  
case where users inadvertently delete folders.

:wes

> -----Original Message-----
> From: "Wesley Craig" <wes at umich.edu>
> To: "David Carter" <dpc22 at cam.ac.uk>
> Cc: "Bron Gondwana" <brong at fastmail.fm>; "Ken Murchison"  
> <murch at andrew.cmu.edu>; "Info Cyrus" <info-cyrus at lists.andrew.cmu.edu>
> Sent: 8/29/06 11:05 AM
> Subject: Re: sync_client bails out after 3 MAILBOXES need upgrading  
> to USER in one   run
>
> On 29 Aug 2006, at 04:35, David Carter wrote:
>> My original code (which we are still running: I'm not in any hurry
>> to upgrade to 2.3) sorts mailbox actions by user. If a single
>> mailbox action associated with a user fails the rest are discarded
>> and a USER event is generated. If the USER event fails it locks the
>> given user out of the mboxlist and tries again. This is close to
>> what you describe above.
>
> Why is 2.3 different?  I'm fairly sure that these issues:
>
> 	4) xfer onto a replicating backend causes sync_client to exit
> 	8) renaming users causes sync_client to exit
>
> would be solved with the algorithm you're using (or the one Bron
> outlined).
>
> :wes


More information about the Info-cyrus mailing list