<!DOCTYPE html>
<html>
<head>
<title></title>
</head>
<body><div>On Fri, Oct 17, 2014, at 01:48 AM, Stephen Ingram wrote:<br></div>
<blockquote type="cite"><div dir="ltr"><div>On Thu, Oct 2, 2014 at 8:48 AM, Stephen Ingram <span dir="ltr"><<a href="mailto:sbingram@gmail.com" target="_blank">sbingram@gmail.com</a>></span> wrote:<br></div>
<div><div defang_data-gmailquote="yes"><blockquote defang_data-gmailquote="yes" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div>On Tue, Sep 16, 2014 at 11:15 PM, Bron Gondwana <span dir="ltr"><<a href="mailto:brong@fastmail.fm" target="_blank">brong@fastmail.fm</a>></span> wrote:<br></div>
</div>
<div><div defang_data-gmailquote="yes"><div><div><blockquote defang_data-gmailquote="yes" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div><u></u><br></div>
<div><div><div><div>On Wed, Sep 17, 2014, at 08:24 AM, Stephen Ingram wrote:<br></div>
<blockquote type="cite"><div dir="ltr"><div>On Tue, Sep 16, 2014 at 3:02 PM, Bron Gondwana <span dir="ltr"><<a href="mailto:brong@fastmail.fm" target="_blank">brong@fastmail.fm</a>></span> wrote:<br></div>
<div><div><blockquote style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div><u></u><br></div>
<div><div>Dumb question - but I don't suppose anything happened to your clock recently?<br></div>
<div> </div>
<div>More non-dumb question, what version of Cyrus?<br></div>
</div>
</blockquote><div> </div>
<div>Sorry, I should have included the version. I'm using 2.4.16 rpms from Invoca Systems. Nothing has happened with the clock. This is the only mailbox that seems to have the problem too, user.ken.Trash. We are running a murder configuration with 2 backends and 2 front ends. Not may users accounts, just large mailboxes. Maybe there is some setting on the mupdate master or somewhere else that is set for 14 days?<br></div>
</div>
</div>
</div>
</blockquote><div> </div>
</div>
</div>
<div>I don't think so. Do you have any entries in the syslog showing the deletes? I'm pretty sure 'auditlog: 1' works in imapd.conf in 2.4.16, so you should be able to add that to see more logging.<br></div>
</div>
</blockquote><div> </div>
</div>
</div>
<div>I finally got a chance to put in auditlog and I see several entries like this everyday:<br></div>
<div> </div>
<div>Oct 1 09:45:41 imap1 imap[7357]: auditlog: expunge sessionid=<imap1.4test.net-7357-1412174740-1> mailbox=<user.ken.Trash> uniqueid=<5f184bff4ee3c346> uid=<170665> guid=<5bbe70214bd4c7979f72977adda664afaa8ebe24><br></div>
<div> </div>
<div>and then:<br></div>
<div> </div>
<div>Oct 1 09:45:41 imap1 imap[7357]: Expunged 19 messages from user.ken.Trash<br></div>
<div> </div>
<div>at then end. The system is now removing everything down to 7 days when "info user.ken.Trash" yields:<br></div>
<div> </div>
<div><div>{user.ken.Trash}:<br></div>
<div> duplicatedeliver: false<br></div>
<div> expire: 30<br></div>
<div> lastpop: <br></div>
<div> lastupdate: 2-Oct-2014 10:39:17 -0500<br></div>
<div> partition: default<br></div>
<div> pop3newuidl: true<br></div>
<div> sharedseen: false<br></div>
<div> size: 7749319<br></div>
</div>
<div> </div>
<div>I did check the client as Alexei had suggested too as I thought the 14 days (and now 7) were a little coincidental, but there was nothing there causing the issue. Now after turning on auditlog, it does show the system removing these mails. Is this expire 30 number stored somewhere that has become corrupt or changed? This is just baffling to me as it seems to only affect this mailbox.<br></div>
</div>
</div>
</div>
</blockquote><div> </div>
<div>After another log search, I see there are messages removed every night. There are dates stretching back 14 days on the file system and 7 days in the actual Trash folder. I can't imagine that this could be a bug in Cyrus as I would have thought others to have seen it by now. I'm guessing perhaps under some unique set of circumstances, the file that contains the expiration information has become corrupt causing the mail to be removed pre-maturely. Does anyone know what file that information is contained within and if it can somehow be regenerated?<br></div>
</div>
</div>
</div>
</blockquote><div> </div>
<div>I assume it's cyr_expire that's cleaning it up?<br></div>
<div> </div>
<div>The likely places are either the command line flags to cyr_expire, the annotations database entry for that folder, or this config item:<br></div>
<div> </div>
<div>{ "expunge_days", 7, INT }<br></div>
<div>/* Number of days to retain expunged messages before cleaning up their<br></div>
<div> index records. The default is 7. This is necessary for QRESYNC<br></div>
<div> to work correctly. If combined with delayed expunge (above) you<br></div>
<div> will also be able to unexpunge messages during this time. */<br></div>
<div> </div>
<div>Note that that is only messages which are already expunged being unlinked from the folder.<br></div>
<div> </div>
<div>Bron.<br></div>
<div> </div>
<div id="sig567075"><div class="signature">--<br></div>
<div class="signature">Bron Gondwana<br></div>
<div class="signature">brong@fastmail.fm<br></div>
<div class="signature"> </div>
</div>
<div> </div>
</body>
</html>