Actually, I was talking rubbish cyr_expire does find the deleted folders older than x days, I just got my dates wrong when looking into it.
apologies, Gavin. On Thu, 16 Sep 2010, gavin.g...@ed.ac.uk wrote: > Hi there, > So is the side effect of deleted folders ending up on the default > partition when delayed delete is switched on on a replicant machine a known > issue for sync_server? A knock on effect of this seems to be that cyr_expire > on the replicant doesn't find these DELETED folders when it runs to do a > purge. > > Could you suggest a safe alternative to cyr_expire in order to purge these > misplace deleted folders? > > regards, > > Gavin Gray > > > On Wed, 15 Sep 2010, Bron Gondwana wrote: > >> On Wed, Sep 15, 2010 at 12:29:18PM +0100, Gavin Gray wrote: >>> Hi there, >>> >>> We have a cyrus murder using replication and we have a few questions >>> about the behaviour we are seeing on our system. >>> >>> 1. cyr_expire on the master doesn't cause any replication to happen. >>> Is that 'correct'? In other words if we want to delete folders from >>> the DELETED heirarchy on the replicant then we need to also run >>> cyr_expire on the replicant? >> >> Yeah, pretty much. >> >>> 2. We're also a little unclear about replication vis a vis the >>> delayed expunge and the unexpunge facility. Could you explain what >>> ought to happen in terms of replication when email is expunged and >>> then possibly unexpunged if anything? >> >> It's a bit messy. Unexpunge is a sin against IMAP by the way, and >> has been replaced with "generate new UID and promote" in 2.4. In >> which case it's just like a new append wit the same flags, and >> replicates like an append :) >> >> 2.3 replication ignores expunges - it's as if they don't exist! When >> the mailbox syncs, it nukes the records that aren't "alive" on the >> master from the replica. If you re-inject them with unexpunge, it >> should find them and sync_combine_commit() the result. I don't know >> if unexpunge inserts replication events though - somewhat doubt it. >> >>> 3. We are seeing a strange anomaly on the replication of deleting a >>> folder. >>> e.g a user deletes a folder >>> the folder goes into the DELETED heirarchy of the partition >>> the user's mailbox is on >>> the folder is also deleted from the replicant as we would expect >>> however the folder on the replicant goes into the DELETED >>> heirarchy on a different partition(the default partition as >>> specified in cyrus.conf). Is this normal? >> >> Replication and partitions is broken in some ways in 2.3. It should >> be better in 2.4 I believe, though I haven't tested it. I'm going to >> be releasing an alpha super-soon (it's been pushed to git.cyrusimap.org >> now!) >> >> Bron. >> >> > > -- > The University of Edinburgh is a charitable body, registered in > Scotland, with registration number SC005336. > > > Gavin Gray Edinburgh University Information Services Rm 2013 JCMB Kings Buildings Edinburgh EH9 3JZ UK tel +44 (0)131 650 5987 email gavin.g...@ed.ac.uk -- The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336. ---- Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
