Between these commits:

http://lists.horde.org/archives/cvs/Week-of-Mon-20071029/071790.html

http://lists.horde.org/archives/cvs/Week-of-Mon-20071029/071791.html

we attempt to stop duplicate mailboxes from being added to the tree 
(after all namespace delimiters have been stripped from the end).



Additionally, code was added which requires the IMAP server to do all 
child folder renaming for us (commit messages not presently available).



These changes are HEAD only.

At the moment I'm not grokking the reasoning that says that both sent 
and sent/ _should_ exist, although I'm pretty sure we handle mailboxes 
without \NoSelect and \NoInferiors just fine (in fact I know we do, 
since that describes most Cyrus inboxes), so I think it's the double 
listing that's getting us...



Anyways the above sounds like the best bet esp. since it'd save us 
some work if the server does the full rename anyway. Michael, that 
make sense to you?

I was referring to the part where you said "I'm disappointed that you 
would take the position that IMP should cater to servers that don't 
comply with the IMAP specs.", but let's move on.
I rather get the impression that to Mark Crispin, anyone who is not 
him is a novice.
Of course that's always among the goals as long as it's reasonable. 
We'll take another look at it.

I did not say "damn anything that doesn't". I said "is there a 
compromise where if you rename the

folder that the user requested, and then ask the server if the 
subfolders have been renamed,

and do them if you need to?"



I have contacted the author of RFC3501. He happens to also be the 
author of the C-client

library, which is the basis for PHP's IMAP function calls. As well, he 
is the author of UW_IMAP.

I said to him:
and he replied:
He also said:

I do not think you are a novice.



I am hoping that you would consider making IMP work with _more_ IMAP servers.

That is demonstrably not true given that IMP _does_ work properly with 
pretty much everything except these MIX folders. Maybe not 100% to 
spec but I don't see how we are violating the spec - we're just not 
taking advantage of it.



And it's fine for you, in this case, to say that we should follow the 
spec and damn anything that doesn't - but in a sense that's what we're 
doing! You're saying we should compensate for the fact that your 
server returns multiple folders with the same name.

I'm disappointed that you would take the position that IMP should 
cater to servers that don't comply with the IMAP specs. Even if it 
broke servers that do comply with the specs. Both UW-IMAP and

Cyrus behave properly and IMP will not work properly with either of them.



Isn't there a way to handle both? What if after you rename the top 
level folder, you then do the

LIST to see if the subfolders have been renamed properly? If they 
haven't, then you rename

the subfolders?

Again, you are missing the point.  If we need to rename sent, we sure 
as heck need to rename all subfolders also.  So if your IMAP server is 
telling us that 'sent/' is a child of 'sent', then we need to rename 
'sent/' also.
And this would be fantastic *if* all IMAP servers followed this.  But 
several don't.  So we need to manually do the renaming ourselves.

The sent-mail folder does not have any subfolders. So even if the IMAP 
server returns both "sent"

and "sent/" as you claim, It still doesn't make any sense for IMP to 
rename the sent-mail

folder twice.



Also, if I rename "a" to "z", it makes no sense for IMP to rename 
"a/b" to "z/b" and then

rename "a" to "z". As RFC3501 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".

i.e., this command:
Should return the following:
a/% means return all elements in the hierarchy under 'a', *not* match 
the string "a/[any character other than the hierarchy delimiter]"  See 
RFC 3501 [6.3.8]

But the problem is your IMAP server is indicating that there are 
folders named *both* 'a' and 'a/'.

No. 'a' is a selectable folder. The new MIX format folders can contain 
both messages and other folders, similar to Cyrus folders.

OK, definitely looks like that IMAP server is broken.  Using the test 
account, a list of all folders gives this:



a002 list "" *

* LIST (\NoInferiors \UnMarked) "/" junk-mail

* LIST () "/" sent

* LIST () "/" a

* LIST () "/" a/b

* LIST () "/" INBOX



A list of the 'a' folder gives the following:



a003 list "" a/%

* LIST () "/" a/

* LIST () "/" a/b



That 'a/' entry should not be there.  It is not a valid folder.  At 
the very least it should have a '\Noselect' flag.  But the IMAP server 
is telling us it is a valid folder, so that's what we have to assume.   
We have no way of knowing before we perform an operation on it whether 
that operation will be successful or not.

The format of folders on the IMAP server should be completely 
transparent to a MUA.  So it sounds like UW-IMAP is incorrectly 
broadcasting both folder names - 'foo' and 'foo/'.

Sounds like a broken IMAP server or c-client library. Michael?

But if you create a folder and then create

subfolders inside, then the folder list will show the expand/collapse

button. The rename of the parent folder will be even more problematic.



E.g. if folder 'a' has subfolder 'b' and I try renaming 'a' to 'c', I get:



Error  Renaming "a/b" to "a/b" failed. This is what the server said:

Error  Renaming "a/" to "a/" failed. This is what the server said:

Error  Renaming "a" to "a" failed. This is what the server said:



Notice that the new name does not contain 'c'.

renaming of MIX format folders (UW-IMAP) doesn't work. MIX format 
folders can contain messages or other folders. IMP tries



Rename sent/ sent-sep-2007/

Rename sent sent-sep-2007



The first rename succeeds. The second fails. But it shouldn't try to do both.



This is especially troublesome with the automatic maintenance rolling 
the sent-mail folder because the user is left with no sent-mail folder.