KDirWatch emitting dirty signal many times for one change

Josef Weidendorfer Josef.Weidendorfer at gmx.de
Tue Mar 23 17:38:40 GMT 2004

On Tuesday 23 March 2004 17:36, David Faure wrote:
> On Tuesday 23 March 2004 14:11, Matthias Kretz wrote:
> > On Tuesday 23 March 2004 12:59, David Faure wrote:
> > > > Couldn't KDirWatch compress the notifications into one signal?
> > >
> > > I thought it already did?
> >
> > Look at the test program I attached to my first email. I get 271
> > notifications with it.
> I know, I was simply referring to an earlier discussion about this problem.
> But I found the answer: the delaying is done in KDirLister, not in
> KDirWatch (see KDirListerCache::slotFileDirtyDelayed). Not sure why.
> I would seem like a good idea to do the delaying in KDirWatch...

KDirWatch currently has different semantic depending on the mechanism: If you 
are using stat polling, it will already delay it. If it uses FAM with a 
polling fam daemon, FAM does the delaying. And if you are using FAM with a 
fam daemon using DNOTIFY, or you are using DNOTIFY directly, there will be no 
delaying. And if you are using FAM for a remote directory, it depends on if 
there is a FAM deamon running on the NFS server and if that FAM daemon is 
using stat polling or DNOTIFY...

Yup, KDirWatch can delay notifications. I will look for it if I have some 
time. Neverless, the DNOTIFY interface should allow for delaying.


More information about the kde-core-devel mailing list