Deleting top-level mailbox with 'delete_mode: delayed'

Simon Matter simon.matter at invoca.ch
Tue Nov 13 07:11:49 EST 2007


> On Nov 5, 2007 6:15 AM, Bron Gondwana <brong at fastmail.fm> wrote:
>>
>> On Fri, Nov 02, 2007 at 01:15:37PM -0400, Brian Wong wrote:
>> > On Nov 2, 2007 12:39 PM, Rudy Gevaert <Rudy.Gevaert at ugent.be> wrote:
>> > >
>> > > Brian Wong wrote:
>> > > > I was testing out Cyrus 2.3.10 and realized that when I set the
>> option
>> > > >
>> > > > delete_mode: delayed
>> > > >
>> > > > I can not delete top-level mailboxes.
>> > > >
>> > > > localhost.localdomain> lm
>> > > > localhost.localdomain> cm user.bwong
>> > > > localhost.localdomain> sam user.bwong <admin_account> c
>> > > > localhost.localdomain> dm user.bwong
>> > > > deletemailbox: Operation is not supported on mailbox
>> > > > localhost.localdomain> lm
>> > > > user.bwong (\HasNoChildren)
>> > > >
>> > > > Disabling the delayed delete gives expected results. The mailbox
>> is
>> > > > deleted as normal. Anyone else confirm this?
>> > >
>> > > I'm just back from holiday (and only catching up on mail).  I always
>> set
>> > > the 'x' permission.  Could you try that?  If that doesn't work, I'll
>> try
>> > > to delete a top level mailbox on Monday (I'm running 2.3.10 in
>> test).
>> > >
>> > > Rudy
>> > >
>> >
>> > localhost.localdomain> lam user.bwong
>> > bwong lrswipkxtecda
>> > admin kxc
>> > localhost.localdomain> dm user.bwong
>> > deletemailbox: Operation is not supported on mailbox
>> >
>> > I think if I did not have the right to delete the mailbox, I would get
>> > a "Permission Denied" instead of the error I am receiving. Let me know
>> > what you find when you try it. I feel that if this is really a bug it
>> > would have been caught before release, but then again I can't think of
>> > anything atypical with my setup that would cause this problem.
>>
>> It's almost certainly caused by the code that checks if you're renaming
>> a "top level mailbox" for a user and special cases it in all sorts of
>> ways.  I never liked that code much!
>>
>> My solution was to make DELETED.user.bwong.46A12345 (or similar) also
>> be considered to be an "INBOX" so it was treated as a user rename.
>> This seems not to be working in your environment, and I'm really not
>> sure why.
>>
>> I don't see anything specially different in our config.
>> fast_rename: yes, but that won't work for you anyway because it's
>> using a not-yet-perfect patch at our end.
>>
>> All our mailbox deletes are done as the admin user.  It won't work
>> if you're not a bona-fide admin (not just a user called admin who
>> happens to have an ACL).  Check the 'admins:' parameter in your
>> imapd.conf.
>>
>> Regards,
>>
>> Bron.
>>
>> (P.S. your username is scarily similar to mine!)
>>
>
> admins: cyradm
>
> localhost.localdomain> sam user.bwong cyradm c
> localhost.localdomain> lam user.bwong
> bwong lrswipkxtecda
> cyradm kxc
> localhost.localdomain> dm user.bwong
> deletemailbox: Operation is not supported on mailbox
>
> The 'admins' parameter seems to be fine. I just didnt want to get
> specific with the configuration and showing that the admin was
> 'cyradm' because I didnt want to confuse anyone with having an admin
> user with the same name as the command.
>
> I really do not know what to do. This is a test box where I removed
> and recreated all the relevant cyrus directories just to make sure I
> was starting from scratch.
>
> Configuration:
> imapidresponse: 0
> allowallsubscribe: 1
> allowplaintext: 1
>
> configdirectory: /var/imap
>
> defaultpartition: ms1
> metapartition_files: header index cache expunge
>
> partition-default: /var/spool/imap
>
> partition-ms1: /var/spool/imap/data1
> metapartition-ms1: /var/spool/imap/meta1
> partition-ms2: /var/spool/imap/data2
> metapartition-ms2: /var/spool/imap/meta2
>
> auth_mech: pts
> pts_module: ldap
>
> admins: cyradm
>
> sasl_pwcheck_method: saslauthd
> sasl_mech_list: plain
>
> <LDAP OPTIONS snipped>
>
> username_tolower: 1
> lmtp_downcase_rcpt: 1
>
> singleinstancestore: 1
>
> munge8bit: 0
> reject8bit: 0
>
> duplicate_db: skiplist
> annotation_db: skiplist
> mboxkey_db: skiplist
> mboxlist_db: skiplist
> ptscache_db: skiplist
> seenstate_db: skiplist
> subscription_db: flat
> tlscache_db: skiplist
>
> expunge_mode: delayed
> delete_mode: delayed

I've just tried a batch delete of mailboxes and hit the same wall.

Mailbox deletion doesn't work anymore with 2.3.10 if "delete_mode:
delayed". If "delete_mode: immediate" it works, but with delayed I get
"deletemailbox: Operation is not supported on mailbox".

Did I miss something? Does anybody have a patch?

Thanks,
Simon



More information about the Info-cyrus mailing list