6 messages in net.sourceforge.lists.courier-usersRe: [courier-users] Re: Recursive REN...
FromSent OnAttachments
Lars UffmannAug 23, 2001 6:58 am.sh
Sam VarshavchikAug 23, 2001 3:16 pm 
Lars UffmannAug 24, 2001 5:31 am.udiff
Tracy SnellAug 27, 2001 8:01 am 
James KnightAug 27, 2001 3:09 pm 
Sam VarshavchikAug 27, 2001 3:19 pm 
Actions with this message:
Paste this link in email or IM:
Paste this link in email or IM:
Atom feed for this thread
Paste this URL into your reader:
Subject:Re: [courier-users] Re: Recursive RENAME BugActions...
From:Lars Uffmann (lu@mediaways.net)
Date:Aug 24, 2001 5:31:26 am
List:net.sourceforge.lists.courier-users
Attachments:
renamehack.udiff - 1k

On Thu, Aug 23, 2001 at 10:16:32PM +0000, Sam Varshavchik wrote:

Lars Uffmann writes:

Hi,

courier-imap fails to RENAME folders when a folder has subfolders. Subfolders will not be renamed when the top level folder is renamed. RFC2060, 6.3.5. says:

if the name has inferior hierarchical names, then the inferior hierarchical names MUST also be renamed. For example, a rename of "foo" to "zap" will rename "foo/bar" (assuming "/" is the hierarchy delimiter character) to "zap/bar".

The following is the output of the attachet renamebug.sh script + the Commands inserted at the right place.

* PREAUTH Ready. L001 CREATE INBOX.a L001 OK "INBOX.a" created. L002 CREATE INBOX.a.a L002 OK "INBOX.a.a" created. L004 RENAME INBOX.a INBOX.b

INBOX.a.a is not a child of INBOX.a, it is a child of INBOX.a. Try: RENAME INBOX.a. INBOX.b.

I would expect INBOX.a.a to be INBOX.b.a after the RENAME.

Why? Technically, you are required to CREATE INBOX.a. before CREATE INBOX.a.a, by RFC 2060, but this is optional with Courier-IMAP. Since you have to create INBOX.a. first, it logically follows that you need to rename the same thing, if you want to rename this whole hierarchy.

INBOX.a and INBOX.a. are two completely separate entities. Doing something to one won't necessary do something to the other.

At least Netscape 4.7 fails to rename Folders recusively. Since it's our companys standard (*sigh*) MUA, I had to make it work. Attached is a patch to imapd.c, wich does a recursive move regardless of the distinction between "INBOX.a" and "INBOX.a.". At least Netscape 6.1 behaves the same way. The patch will only compile when configure was called with the `--enable-workarounds-for-imap-client-bugs' option.

regards,

Index: imapd.c =================================================================== RCS file: /cvsroot/courier/courier/imap/imap/imapd.c,v retrieving revision 1.65 diff -u -r1.65 imapd.c --- imapd.c 2001/06/23 02:02:52 1.65 +++ imapd.c 2001/08/24 12:29:24 @@ -1867,9 +1867,7 @@ fetch_free_cache(); if (strcmp(mailbox, ".")) { - if (is_reserved(mailbox) || - is_reserved(new_mailbox) || - hier_rename(mailbox, new_mailbox, ishier)) + if (is_reserved(mailbox) || is_reserved(new_mailbox)) { free(mailbox); free(new_mailbox); @@ -1877,6 +1875,35 @@ writes(" NO Cannot rename this folder.\r\n"); return (0); } +#if IMAP_CLIENT_BUGS + /* rename recursive: all subfolder */ + if (hier_rename(mailbox, new_mailbox, 1)) + { + free(mailbox); + free(new_mailbox); + writes(tag); + writes(" NO Cannot rename this folder.\r\n"); + return (0); + } + /* rename the base folder */ + if (hier_rename(mailbox, new_mailbox, 0)) + { + free(mailbox); + free(new_mailbox); + writes(tag); + writes(" NO Cannot rename this folder.\r\n"); + return (0); + } +#else + if (hier_rename(mailbox, new_mailbox, ishier)) + { + free(mailbox); + free(new_mailbox); + writes(tag); + writes(" NO Cannot rename this folder.\r\n"); + return (0); + } +#endif } else /* Renaming INBOX not yet supported */ {