Evo 2.6.1 and cyrus-imapd 2.3.1 folder rename problem

From: Scott Russell (no email)
Date: Wed May 10 2006 - 18:34:46 EDT

  • Next message: Andrey Kolbasenko: "pop3 slow respond"

    I saw something really silly today. At least part of it seems to be the
    fault of the client but it seems like the cyrus server did something
    really stupid on it's own.

    The user had the following (partial) folder structure:


    The user wanted to place the iiosb folder into the iiosb-admin folder
    and attempted to do so using Evo 2.6.1 on our cyrus-imapd 2.3.1 server.
    Here's the section of the trace:

         1 <1147297937<B00263 UNSUBSCRIBE iiosb
         2 >1147297937>B00263 OK Completed
         3 <1147297937<B00264 UNSUBSCRIBE iiosb-admin
         4 >1147297937>B00264 OK Completed
         5 <1147297937<B00265 UNSUBSCRIBE iiosb.Successes
         6 >1147297937>B00265 OK Completed
         7 <1147297937<B00266 RENAME iiosb iiosb-admin.iiosb
         8 >1147297937>* OK rename iiosb iiosb-admin.iiosb
         9 >1147297938>* OK rename iiosb.Successes iiosb-admin.iiosb.Successes
        10 >1147297938>B00266 OK Completed
        11 <1147297938<B00267 RENAME iiosb iiosb-admin.iiosb
        12 >1147297938>B00267 NO Mailbox does not exist
        13 <1147297938<B00268 RENAME iiosb-admin iiosb-admin.iiosb.admin
        14 >1147297938>B00268 OK Completed
        15 <1147297938<B00269 RENAME iiosb.Successes
        16 >1147297938>B00269 NO Mailbox does not exist
        17 <1147297938<B00270 SUBSCRIBE iiosb-admin.iiosb
        18 >1147297938>B00270 OK Completed
        19 <1147297938<B00271 SUBSCRIBE iiosb-admin.iiosb.admin
        20 >1147297938>B00271 OK Completed
        21 <1147297938<B00272 SUBSCRIBE iiosb-admin.iiosb.Successes
        22 >1147297939>B00272 OK Completed
        23 <1147297939<B00273 UNSUBSCRIBE iiosb
        24 >1147297939>B00273 OK Completed

    Things look okay up to line 7 where the client issues the RENAME
    command. Cyrus responds on lines 8 - 10 by renaming both the top level
    INBOX.iiosb and INBOX.iiosb.Successes folder. (Is it normal for the
    cyrus server to automatically rename subfolders of the parent folder
    too?) The client then tries to rename the now missing
    INBOX.iiosb.Successes folder on lines 11 and 12, this obviously fails as
    the server took care of it in response to line 7.

    Things get really nutty at line 13. The client (not the user) issues a
    rename for INBOX.iiosb-admin to INBOX.iiosb-admin.iiosb.admin and cyrus
    let's this happen. This leaves the file system with a directory
    user/drfickle/iiosb-admin/iiosb/* and in the iiosb-admin directory on
    the file system there are no cyrus.* files!

    Evo was obviously delusional when issuing the command on line 13 but I
    don't think cyrus should have handled it that way. It left several
    folders inside of user/drfickle/iiosb-admin that couldn't be accessed
    because the iiosb-admin directory was lacking cyrus.* files.

    Thoughts? (Other than evo sucks)

    Scott Russell <>
    IBM Linux Technology Center, System Admin
    Cyrus Home Page: http://asg.web.cmu.edu/cyrus
    Cyrus Wiki/FAQ: http://cyruswiki.andrew.cmu.edu
    List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html

  • Next message: Andrey Kolbasenko: "pop3 slow respond"

    Hosted Email Solutions

    Invaluement Anti-Spam DNSBLs

    Powered By FreeBSD   Powered By FreeBSD