mailboxes.db vs IMAP client irregularities

[Patrick Boutilier]

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

>
> Steve

-------------- next part --------------
A non-text attachment was scrubbed...
Name: boutilpj.vcf
Type: text/x-vcard
Size: 286 bytes
Desc: not available
Url : http://lists.andrew.cmu.edu/pipermail/info-cyrus/attachments/20120519/44ca7947/attachment-0001.vcf