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