Version: 3.2.1 (using KDE 3.2.1, SuSE) Compiler: gcc version 3.3.3 (SuSE Linux) OS: Linux (i686) release 2.6.5-7.108-smp If I have more than 3900 files in a directory and try to delete them in Konqueror, the files start deleting, then at the magic number of 3900, the deleting freezes. It always stops at 3900.
At least deleting (to the trash) is extremely slow. I did 5000 empty files and konqueror deletes those about 1400/10min rate. CPU usage is limiting factor, I've P3 700Mhz. Process dialog doesn't refresh, it stays at 0%. But I couldn't reproduce the total hang at 3900, finally directory was empty.
Well the Delete Progress dialog freezes, and I did not wait much longer. I had three simultaneous directories deleting, which all had more than 10,000 files. My machine is A Dell 2.8G with 1G memory, so machine resources is not a problem. I have since cleared out the directories, using MS Windows, or deleting them with the RM and xargs commands. I can try and reproduce this again, but I had it happen all the time. Anything else you want me to check?
I've also seen this problem on Konqueror 3.2.2 in Debian (Sarge). Since the progress dialogue goes in steps of 300, I guess the real limit is between 3900 and 4199. Though in the case I have, 100000 characters in the filenames also comes in this range. When it stops, CPU usage drops to essentially zero. And there was no progress for at least 5 minutes, whereas it had been going at a decent rate (>30 files/second) prior to that point. I've not tried deleting to trash as that would fill $HOME well before the 3900 file make had been reached.
The slowness in #1 I see too and it's because kdirlister uses O^2 algorithms in KDirListerCache::FilesRemoved. That takes a lot of CPU. The problem with the 3900 files I can only reproduce with binaries, but for those I can 100%. My CVS deletes them all.
CVS commit by waba: Don't block internal notification pipe when we get 4096 or more changes before handling the event loop. BUG: 90473 M +4 -2 kdirwatch.cpp 1.111 --- kdelibs/kio/kio/kdirwatch.cpp #1.110:1.111 @@ -222,4 +222,6 @@ KDirWatchPrivate::KDirWatchPrivate() fcntl(mPipe[0], F_SETFD, FD_CLOEXEC); fcntl(mPipe[1], F_SETFD, FD_CLOEXEC); + fcntl(mPipe[0], F_SETFL, O_NONBLOCK | fcntl(mPipe[0], F_GETFL)); + fcntl(mPipe[1], F_SETFL, O_NONBLOCK | fcntl(mPipe[1], F_GETFL)); mSn = new QSocketNotifier( mPipe[0], QSocketNotifier::Read, this); connect(mSn, SIGNAL(activated(int)), this, SLOT(slotActivated())); @@ -275,6 +277,6 @@ void KDirWatchPrivate::slotActivated() { #ifdef HAVE_DNOTIFY - char dummy_buf[100]; - read(mPipe[0], &dummy_buf, 100); + char dummy_buf[4096]; + read(mPipe[0], &dummy_buf, 4096); if (!rescan_timer.isActive())
I have reopened bug 43356 for the slowness aspect of this bug.