mailboxes.db vs IMAP client irregularities

Stephen Ingram sbingram at gmail.com
Sat May 19 15:56:44 EDT 2012


On Sat, May 19, 2012 at 12:40 PM, Patrick Boutilier
<boutilpj at ednet.ns.ca> wrote:
> On 05/19/2012 04:02 PM, Stephen Ingram wrote:
>>
>> On Sat, May 19, 2012 at 10:58 AM, Patrick Boutilier
>> <boutilpj at ednet.ns.ca>  wrote:
>>>
>>> On 05/19/2012 01:51 PM, Stephen Ingram wrote:
>>>>
>>>>
>>>> I'm running 2.4.13 from the invoca rpms on CentOS 5.8. I recently had
>>>> an issue with a folder in a mailbox that would not show any
>>>> subfolders. I created a new folder 'folder2' and moved all of the
>>>> subfolders to it and then performed a reconstruct on the new set of
>>>> folders and everything worked. Now I deleted the old folder 'folder'
>>>> from the file system and then (after it wouldn't go away from the
>>>> cyradm listing) used cyr_dbtool to manually remove it (and the
>>>> subfolders) from the mailboxes.db file. The old folders and subfolders
>>>> are now gone, however, I can't (using the IMAP client) rename
>>>> 'folder2' back to 'folder' as when I do, the subfolders are not
>>>> visible.
>>>>
>>>> I've dumped the mailboxes.db file to a flat file to look and see if
>>>> there is anything in there that wasn't visible in cyradm or using
>>>> cyr_dbtool show. Everything is as expected except there are some
>>>> DELETED.user.xxx.folder entries at the top. Are you not allowed the
>>>> create folders with the same name you've just deleted? Where are these
>>>> DELETED folders actually stored and how long does it take them to go
>>>> away? (I'm not using delayed expunge.)
>>>
>>>
>>>
>>> Sounds like you are using delayed delete. Mine show up in
>>> /imap/mail/C/DELETED/  . How long they stay around depends on when you
>>> run
>>> cyr_expire and what parameters you give it.
>>>
>>>
>>> Man page entries:
>>>
>>> deletedprefix: DELETED
>>>            If  "delete_mode"  set  to  be  "delayed",  the  prefix for
>>> the
>>> deleted mailboxes hierarchy.  The hierarchy delimiter will be
>>> automatically
>>> appended.
>>>
>>> delete_mode: immediate
>>>            The manner in which mailboxes are deleted. "immediate" mode is
>>> the default  behavior  in  which  mailboxes  are  removed immediately.
>>> In
>>> "delayed" mode, mailboxes are renamed to a special hiearchy defined by
>>> the
>>> "deletedprefix" option to be removed later by cyr_expire.
>>>
>>>            Allowed values: immediate, delayed
>>
>>
>> I don't have any entry in imapd.conf for delete_mode so I'm thinking
>> that it's using the default of immediate. I did check the file system
>> again and I can't find those DELETED folders anywhere, so I'm guessing
>> that mailboxes.db is just wrong probably because of some bug. At your
>> suggestion, I checked cyr_expire and it is set to 3 days, so perhaps
>> that's my issue. Maybe those entries in mailboxes.db will go away on
>> their own after 3 days. I think I might wait just out of curiosity and
>> then upgrade to 2.4.16 to see if these mailbox naming issue (bug
>> 2685?) is solved.
>>
>> I wonder if there is any harm in removing those DELETED entries in
>> mailboxes.db if I can't find them anywhere in the file system?
>
>
> I am thinking the worst that would happen is you get an I/O error if the
> DELETED hierarchy really doesn't exist.
>
> Have you tried mbpath? For example:
>
>  [root at student ~]# /usr/local/cyrus/bin/mbpath DELETED.user.whoj.4FB1557F
>
> /imap/mail/C/DELETED/user/whoj/4FB1557F


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.

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.

Thanks, again. I never would have found those files.

Steve


More information about the Info-cyrus mailing list