Changes have been made in Git for this ticket:

Improved display of mailboxes with UTF7-IMAP encoded data
Bug #8286 did not affect git master, but these changes do clean up some
lingering issues with title/tooltip displays of mailboxes with
UTF7-IMAP encoded data. Also, remove some unneeded DOM ID declarations
and some unneeded mailbox name encoding.

http://git.horde.org/diff.php/imp/js/src/DimpBase.js?rt=horde-git&r1=7b83a6940f023cd40760c1b9e9945b34a1ec2a6c&r2=faa78c427464e73c173b49d7a05b3871b8cd5dd1
http://git.horde.org/diff.php/imp/lib/DIMP.php?rt=horde-git&r1=a780c25482037056921c32e29cc93d255b6a1da2&r2=faa78c427464e73c173b49d7a05b3871b8cd5dd1

This is an appropriate patch and has been applied to DIMP 1.1.3.  IMP 
5.0 was unaffected by this bug (folder naming was rewritten during the 
IMAP library switchover).

Changes have been made in CVS for this ticket:

http://cvs.horde.org/diff.php/dimp/docs/CHANGES?rt=horde&r1=1.69.2.74&r2=1.69.2.75&ty=u
http://cvs.horde.org/diff.php/dimp/imp.php?rt=horde&r1=1.194.2.37&r2=1.194.2.38&ty=u

Attached is a proposed patch.



The patch calls String::convertCharset only on the new folder at the 
beginning, not the whole structure at the end as $new_parent enters 
the function already encoded.



An alternative would perhaps be to decode $old and $new_parent at the 
beginning and leave the String::convertCharset at its current place.

It at least fixes my problem, but I am not too deep into (d)imp to 
verify that it doesn't break something else, please verify and apply 
whatever fits best :)

The culprit seems to be dimp/imp.php:253 which calls 
String::convertCharset() from lib/Horde/String.php everytime a Folder 
is renamed:



$new = String::convertCharset($new, NLS::getCharset(), 'UTF7-IMAP');



RFC 2060 at 5.1.3 says:

'The character "&" (0x26) is represented by the two-octet sequence "&-".'



So the problem appears to be that an already encoded folder gets 
encoded again as the escape sequence contains a character ("&") which 
itself is encoded again the next time you run the encode function on 
it, which explains why it turns the starting character of an encoded 
folder sequence (like "test&APY-" into "test&-APY-") and after that 
happened, the folder is broken.

Typo, correct bug # is 7414

When moving ("renaming") a folder into a (sub-)folder where the target 
folder or one of its parents contains an umlaut it gets encoded the 
wrong way (the file name on the file system is already wrong).

Note that this does not happen when creating a new folder, for example.



The attached image shows initial and final folder list, steps how to 
reproduce and how to wrongly encoded file name looks like, which 
should give you a better idea of what's happening than lots of text.



This is the same behaviour as the initial report on #7417 but with a 
clear way to reproduce and information what goes wrong.