Bug 77846

I believe that http://bugs.kde.org/show_bug.cgi?id=79512 is a duplicate of this.

I believe that http://bugs.kde.org/show_bug.cgi?id=79512 is a duplicate of this bug.

Sorry for the duplicate post. Just to clarify, this bug is for when Kfind is searching large folders with the "include subfolders" checked. The UI freezes and never comes back, which means Kfind has to be killed. This bug is still evident in KDE 3.3.

That may be what the Debian bug report says, but it isn't what this report says, and the suggested solution (starting a separate thread) won't necessarily fix bug 79512.

Even when functioning normally (ie, not locking up), the kfind UI fails to update until it receives the results from the find process.  This is especially evident when searching in large directories.  This behaviour is a separate bug imho.

If someone wants to mark this a duplicate of bug 79512 I'll be happy to open a new bug for the (less important) 'UI-fails-to-update' behaviour.

* Ben Burton [Wed, 17 Mar 2004 10:43:11 +1100]:

> > I am trying to use kfind to seach /usr which, at 1.7GB, is one of the 
> > larger directories in my filesystem.  I have "include subfolders" 
> > checked.  It seems to work alright for most directories, but when I ask 
> > it to search a large one, it appears to hang.

> I've just tested this and certainly kfind is not refreshing itself while
> the search takes place.  At the very least (given that find operations
> can be slow), kfind should have a separate thread running that updates
> the GUI (and preferably gives some kind of progress reporting as well).

  I can't reproduce now with KFind from KDE 3.3. I've search in /usr for
  files which contain the text "hello". (File Type: All Files & Folders,
  Include subfolders checked.)

  the UI does not freeze, and the resutls panel is incrementally
  updated. the "Stop" button works at any stage of the search.

  can anybody confirm?

I can confirm this in KDE 3.3 on Gentoo.  A large search (not using the index) hogs the UI completely.

I use KDE 3.3 as well, and the GUI of kfind does not block during a search. During a large search (searching vor *kde* in /) the guis is still accessible, all the buttons work, etc..

So I guess this bug has been resolved.

I have KDE on two different machines. What is strange is that one machine (which is a fully updated Debian Sid machine), the bug shows up. On my home machine, which does not have completely updated Debian Sid files, the bug does not occur. The bug on the work machine is as follows: when searching large directories with "include subfolders", kfind freezes. When "include subfolders" is not selected, it does not freeze. The bug first showed up in KDE 3.2, and continues in 3.3. Is there any way I can help debug the problem? Unfortunately, my work machine is behind a firewall so having someone do a remote desktop connection will not work. So if someone can give me something to look for, I can do my best to get the information needed.

For those having this problem - kill famd and try again.  IT works for me every time.

Using KDE 3.3

Killing famd worked for me. Now to find out why it is causing problems with kfind. I've remove fam from my debian files, because I can't determine its importance and none of the other programs seem to depend on it. I guess if I need it later, I can reinstall it.

CVS commit by waba: 

Disable recursively watching for updates
BUG: 68220
BUG: 77854
BUG: 77846
BUG: 79512
BUG: 85802


  M +13 -0     kfinddlg.cpp   1.25


--- kdebase/kfind/kfinddlg.cpp  #1.24:1.25
@@ -127,4 +127,16 @@ void KfindDlg::startSearch()
   dirwatch->addDir(query->url().path(),true);
 
+#if 0
+  // waba: Watching for updates is disabled for now because even with FAM it causes too
+  // much problems. See BR68220, BR77854, BR77846, BR79512 and BR85802
+  // There are 3 problems:
+  // 1) addDir() keeps looping on recursive symlinks
+  // 2) addDir() scans all subdirectories, so it basically does the same as the process that
+  // is started by KQuery but in-process, undoing the advantages of using a seperate find process
+  // A solution could be to let KQuery emit all the directories it has searched in.
+  // Either way, putting dirwatchers on a whole file system is probably just too much.
+  // 3) FAM has a tendency to deadlock with so many files (See BR77854) This has hopefully
+  // been fixed in KDirWatch, but that has not yet been confirmed.
+
   //Getting a list of all subdirs
   if(tabWidget->isSearchRecursive() && (dirwatch->internalMethod() == KDirWatch::FAM))
@@ -134,4 +146,5 @@ void KfindDlg::startSearch()
       dirwatch->addDir(*it,true);
   }
+#endif
 
   win->beginSearch(query->url());