Version:            (using KDE 4.3.1)
Compiler:          gcc (Ubuntu 4.4.1-4ubuntu4) 4.4.1 Packaged by ubuntu team for ubuntu 9.10
OS:                Linux
Installed from:    Ubuntu Packages

OS/Version: (K)ubuntu karmic latest (1-oct-2009) alpha with KDE-4.3.1

When configuring an IMAP e-mail account in KMail, and opening one of the account folders, several things go wrong, which are probably related, hence I put them in one bug report:

1.- I get an error-message for every sub-folder saying:
 'Cannot open file "~/.kde/share/apps/kmail/imap/.286385175.directory/.XXX.directory/YYY":
No such file or directory'

If I check the mentioned directory from a terminal, before I click on "OK" in the message box, I can verify the file exists and has read and write access.

2.- In my case the IMAP account contains a tree of folders and sub-folders. There are probably more than 1000 directories. So after a long while holding down the [Enter] key to click through all the OK buttons in the almost endless storm of error messages, the error message text chages to:

'Cannot open file "~/.kde/share/apps/kmail/imap/.286385175.directory/.XXX.directory/YYY":
Too many open files'

And sometimes in between there is a shorter error message dialog saying:

'Error while creating file XXX: Too many open files'

Looking inside /proc/<pid of kmail>/fd/, there are indeed 1000 open file-descriptors. Apparently this is the pre-configured maximum on my system, but anyway, kmail should NEVER keep all those files open in the first place.

I cannot use KMail like this, and in fact I never made it through all the error messages, to see what happens then. Every time I restart KMail, and repeating the procedure, the directories previously created are removed again, and the pain starts over!

Could this be a race-condition between two threads?

Additional information: The home directory (~) is on an NFS mounted drive, and this has been working fine for years throughout the KDE-3.x series. Before running KDE4 for the first time, I removed my .kde directory just in case.