serious kfind and famd problems, help needed

Josef Weidendorfer Josef.Weidendorfer at
Mon Jan 17 18:33:41 GMT 2005

On Sunday 09 January 2005 14:34, Alexander Neundorf wrote:
> Hi,
> famd seems to cause serious problems with kfind:
> I don't have fam installed so I can't reproduce and fix it.
> Could somebody who has fam installed please have a look ?
> Thanks
> Alex


the following code in kfinddlg.cpp looks quite suspicious:
  //Getting a list of all subdirs
  if(tabWidget->isSearchRecursive() && (dirwatch->internalMethod() == 
    QStringList subdirs=getAllSubdirs(query->url().path());
    for(QStringList::Iterator it = subdirs.begin(); it != subdirs.end(); ++it)
Why does anybody want to add dirWatches for *all* directories searched?
Even more strange: Why is this only enabled when FAM is used?

But if you look at the code of getAllSubdirs(), you partly will kow why this 
can lock up:
  for(QStringList::Iterator it = dirs.begin(); it != dirs.end(); ++it)
If the start dir is "/", this will freeze kfind GUI while scanning your whole 
harddisk. Such potentially long lasting code parts should be done in chunks, 
triggered by timer events from the main loop (or in another thread).

But it gets better: Doing a strace on kfind, I get 
{st_mode=S_IFREG|0644, st_size=559, ...}) = 0

Why is linux appearing 10x in this path ??!?
Looking into DRI/drm, I see that linux is a symlink to ".". So obviously 
getAllSubdirs() deadlocks with recursive symlinks.

And this really has *nothing* to do with fam at all, but unfortunately for 
fam, this buggy getAllSubdirs() is only called when fam is used, triggering 
this deadlock.

I can understand that fam looks strange to some people, but this almost looks 
like somebody wanting to kill good old fam's fame by introducing bugs which 
look like fam being the culprit. Sorry, couldn't resist ;-)

Good luck fixing this,

PS: I simply would remove the above cited if-body.

More information about the kde-core-devel mailing list