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