Fri, 10 Apr 2026 01:27:06 +0000 https://bugs.horde.org/ticket/8286 Moving folders containing umlauts may cause misencoded folder names 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. Fri, 15 May 2009 20:23:26 +0000 https://bugs.horde.org/ticket/8286#t54200 > This is the same behaviour as the initial report on #7417 but with a > clear way to reproduce and information what goes wrong. Typo, correct bug # is 7414 Fri, 15 May 2009 20:26:08 +0000 https://bugs.horde.org/ticket/8286#t54201 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. Mon, 18 May 2009 08:08:44 +0000 https://bugs.horde.org/ticket/8286#t54222 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 :) Mon, 18 May 2009 09:23:29 +0000 https://bugs.horde.org/ticket/8286#t54225 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 Mon, 18 May 2009 22:48:34 +0000 https://bugs.horde.org/ticket/8286#t54232 > Attached is a proposed patch. 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). Mon, 18 May 2009 22:50:42 +0000 https://bugs.horde.org/ticket/8286#t54233 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 Wed, 13 Jan 2010 00:02:34 +0000 https://bugs.horde.org/ticket/8286#t57563