mailboxes.db vs IMAP client irregularities

[Stephen Ingram]

On Sat, May 19, 2012 at 1:28 PM, Bron Gondwana <brong at fastmail.fm> wrote:
> On Sat, May 19, 2012 at 12:56:44PM -0700, Stephen Ingram wrote:
>> Wow, thanks! I didn't know about that command. It exposed them!
>> Strange, they were in /var/spool/imap/u/DELETED/ (my mailbox root is
>> /var/spool/imap). I'm not sure why they wouldn't be in
>> /var/spool/imap/j/user/jmaxwell (jmaxwell is the user), but perhaps
>> it's because I haven't defined deleted_prefix as you pointed out
>> earlier. Maybe /var/spool/imap/u/DELETED is the default.
>
> Hashing is on the second part of the name, rather uninteligently,
> no matter what the name - hence it's hashing on:
>
> DELETE.user.x
>       ^
>
> :)
>
>> Looking at all of the files in there, several are older than the 3
>> days they are supposed to be. I'm guessing that means there was a bug
>> somewhere. I guess I should remove all of these, reconstruct the
>> mailboxes.db to match and then probably upgrade as Bron suggested.
>
> No - the files will have the delivery date as their age.  The interesting
> bit is the final part of the folder name, which is actually a 32 bit
> unix timestamp in hex format (yes, really).

Wow, I never stopped being amazed by the really clever hidden things
in cyrus-imap!

> cyr_expire will clean it up.  Don't mess with the filesystem under cyrus
> if you don't have to.

OK, this must be working or I would have tons of DELETED files in
there. However, I see stuff from April that is not gone yet. And, yes,
I actually converted the hex timestamp to a date an it says April too,
certainly more than the 3 day expire time. Hopefully this stuff will
be taken care of when I upgrade to 2.4.16 too!

BTW, I love 2.4. I've been using now for several months and it is such
a HUGE improvement from 2.3. Everything is faster, replication works
better, it's like a whole new program!

Steve