delayed delete

[Wesley Craig]

I hate replying to myself...

On 01 Nov 2006, at 14:51, Wesley Craig wrote:
> I've updated this bug report:
>
> 	https://bugzilla.andrew.cmu.edu/show_bug.cgi?id=2871
>
> to include a patch adding support for a configuration option,  
> delete_mode, which takes the options "delayed" and "immediate".   
> The patch saves certain kinds of deleted mail in the cyrus spool  
> hierarchy.  Patch hasn't been tested out of production, tho we're  
> expecting to deploy it in production at UMich soon.  Comments welcome.

 From the bug report:

> Open issues: cyr_expire should be modified to expire mailboxes in  
> the deleted. hierarchy.  unexpunge (or a similar routine) should  
> allow mailboxes to be undeleted.  The sync protocol doesn't provide  
> enough detail to tell the difference between a mailbox being  
> destructively deleted and a mailbox being successfully moved to  
> another host.

We're deploying this code in production at UMich shortly.  We're  
going to use a simple shell script to implement the cyr_expire  
functionality and (effectively) a few shell commands plus reconstruct  
to implement undelete functionality.  I'm happy to supply C code to  
implement these functions, once I've gotten some acknowledgment of  
the current work.

In our risk analysis, I think the lack of differentiation in the sync  
protocol is actually a virtue.  If the sync protocol allowed the  
primary backend to "really delete" data from the replica, then  
operator error on the primary backend would be more likely to cause  
unrecoverable data loss.  As it stands, unrecoverable data loss can  
only be caused by operator malfeasance.  In all likelihood, tape  
backups would be vulnerable to the same sort of malfeasance.  I'm  
considering the sync protocol issue closed.

:wes