This bug is still present in KDE 4.11.1.

Some more test results:

After creating new folders, these new ones are visible straight away in the serverside subscription list, but not in the local subscription list.  Changing various subscription settings makes no difference.

A second attempt to create a folder (correctly) fails because the folder already exists - but the folder still doesn't appear.

Folders created by other IMAP clients are treated the same way (ie: are not in the folder list).

Switching between normal and disconnected IMAP modes (and back) made no difference.  Explicitly updating the parent folder and all of its subfolders made no difference.

After restarting both Akonadi and Kontact, one of three new folders I created to test with appeared in the normal folder list.

I am also affected by the issue.

The first time I was hit by this, I did the "workaround" of deleting the entire akonadi database, which worked for me.

I just noticed today (after trying to add a folder again), that the problem seems to be the insert statement in the akonadi database.

Akonadi prints the following message to the console:
> Error during executing query "INSERT INTO CollectionTable (remoteId, remoteRevision, name, parentId, resourceId, cachePolicyInherit, isVirtual) VALUES (:0, :1, :2, :3, :4, :5, :6)" :  "Duplicate entry '390-DevLoL' for key 'CollectionTable_parentAndNameIndex' QMYSQL3: Unable to execute statement"

When I connected manually to the akonadi mysql database, I noticed a naming problem:

mysql> select id, remoteId, name from collectiontable where resourceId = 26;
+------+----------------------------------------------+----------------------+
| id   | remoteId                                     | name                 |
+------+----------------------------------------------+----------------------+
|  407 | .INBOX                                       | INBOX                |
| 1441 | /DevLoL                                      | DevLoL               |
+------+----------------------------------------------+----------------------+
(most rows removed for privacy/brevity)

All the folders that work correctly have the remoteId field beginning with a dot, whereas the non-working folders begin with a slash.

Manually fixing the remoteId causes kmail to display the folder correctly.

I guess that kmail uses the incorrect value when creating the folder?

Could you please re-test with KDE 4.11.3? There should be some bugfixes wrt IMAP separator.

After testing with 4.11.3, I am no longer able to reproduce the buggy behaviour.
It seems to be working fine!

I just checked again after doing a dist-upgrade, and the problem persists.

Using kmail on Debian unstable:
$ kmail --version
Qt: 4.8.6
KDE Development Platform: 4.11.3
KMail: 4.11.3

I tested also with 4.11.3 and can confirm that a new folder (in root of imap) is created on the server by kmail but is not shown in kmail.
The akonadi db contains the new folder:

| id  | remoteId | remoteRevision | name  | parentId | resourceId | subscribed | cachePolicyInherit | cachePolicyCheckInterval | cachePolicyCacheTimeout | cachePolicySyncOnDemand | cachePolicyLocalParts | queryString | queryLanguage | isVirtual |
+-----+----------+----------------+-------+----------+------------+------------+--------------------+--------------------------+-------------------------+-------------------------+-----------------------+-------------+---------------+-----------+
| 438 | .test1   |                | test1 |      432 |         23 |          1 |                  1 |                       -1 |                      -1 |                       0 | NULL                  | NULL        | NULL          |         0 |

restarting only kmail shows the new folder.

Martin is right: kmail 4.11.3 shows the folder after a restart.

Deleting this new "test1" folder deletes the folder in the akonadi db but immediately recreates it again (it will get a new id).
However, if the folder does contain a mail, the deletion works correctly.

(In reply to comment #5)
> After testing with 4.11.3, I am no longer able to reproduce the buggy
> behaviour.
> It seems to be working fine!

I must take that back.  After more usage, I'm still seeing this problem.

Steve

Also - restarting kmail (or even rebooting) does not show me some folders.  I get this when a folder is created by kmail on another machine.

This is a bug in the ETM for which I have a patch in progress.

Also note that this bug is about successfully creating a folder that is afterwards not visible in kmail until restarted. The otherissue with the separator is separately handled in Bug 323844.

Git commit 9eac241c9dde13af7ae8a2875efc96cb0da23fc7 by Christian Mollekopf.
Committed on 20/01/2014 at 12:49.
Pushed by cmollekopf into branch 'master'.

React to collection changes that cause a collection to match a filter.

Some obvious cases were:
* if you create a collection in kmail it is not displayed until kmail is
restarted (the mimetype arrives via a dataChanged signal)
* kolab folders were visible in kmail until restarted

Those cases are now properly handled by adding/removing the collection as
appropriate.
REVIEW: 115145

M  +24   -13   akonadi/entitytreemodel_p.cpp
M  +9    -0    akonadi/entitytreemodel_p.h

http://commits.kde.org/kdepimlibs/9eac241c9dde13af7ae8a2875efc96cb0da23fc7

Hi,

Did this fix make it into 4.12.2? I'm still seeing this problem.

Steve

No, the fix will be available in 4.13.

I can confirm that this works as expected in 4.13 for me.
A newly created folder is visible immediately now.

Thank you!

It is now impossible to create such a container from within KMail but:
 1. The container I created back in 2011 still exists.
 2. KMail does not let me subscribe to it.
 3. Accordingly, there is no way to delete it.
 4. However, it is not possible to create a folder of the same name.

All in all, my user experience is crippled.