messages removed before expire

[Stephen Ingram]

On Thu, Oct 2, 2014 at 8:48 AM, Stephen Ingram <sbingram at gmail.com> wrote:

> On Tue, Sep 16, 2014 at 11:15 PM, Bron Gondwana <brong at fastmail.fm> wrote:
>
>>  On Wed, Sep 17, 2014, at 08:24 AM, Stephen Ingram wrote:
>>
>> On Tue, Sep 16, 2014 at 3:02 PM, Bron Gondwana <brong at fastmail.fm> wrote:
>>
>>
>> Dumb question - but I don't suppose anything happened to your clock
>> recently?
>>
>> More non-dumb question, what version of Cyrus?
>>
>>
>> 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?
>>
>>
>> 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.
>>
>
> I finally got a chance to put in auditlog and I see several entries like
> this everyday:
>
> 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>
>
> and then:
>
> Oct  1 09:45:41 imap1 imap[7357]: Expunged 19 messages from user.ken.Trash
>
> at then end. The system is now removing everything down to 7 days when
> "info user.ken.Trash" yields:
>
> {user.ken.Trash}:
>   duplicatedeliver: false
>   expire: 30
>   lastpop:
>   lastupdate:  2-Oct-2014 10:39:17 -0500
>   partition: default
>   pop3newuidl: true
>   sharedseen: false
>   size: 7749319
>
> 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.
>

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?

Steve
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.andrew.cmu.edu/pipermail/info-cyrus/attachments/20141016/32173440/attachment.html