KDirWatch issue

Albert Astals Cid aacid at kde.org
Mon May 8 14:14:47 UTC 2017


El dissabte, 6 de maig de 2017, a les 10:44:42 CEST, David Faure va escriure:
> On mercredi 3 mai 2017 12:05:47 CEST Albert Astals Cid wrote:
> > El dimecres, 3 de maig de 2017, a les 11:53:02 CEST, Albert Astals Cid va
> > 
> > escriure:
> > > El dilluns, 24 d’abril de 2017, a les 20:08:26 CEST, Martin Koller va
> > > 
> > > escriure:
> > > > Hi,
> > > > 
> > > > just wondering if I'm doing something wrong or there really is a bug
> > > > in
> > > > KDirWatch (I'm on openSuse Leap 42.2, KF5 5.33.0)
> > > > 
> > > > From the docs I understand that when I call
> > > > 
> > > > KDirWatch::stopDirScan(dir);
> > > > ... create files in the dir ...
> > > > KDirWatch::restartDirScan(dir)
> > > > 
> > > > it should not emit the dirty signal when I run this, right ?
> > > 
> > > Correct. [...]
> 
> Incorrect, I think, see below.
> 
> > > I could try to spend more time (and making the code more complex) to
> > > work,
> > > but then i thought, what's the point? We already have removeDir/addDir
> > > that works.
> 
> I think the point is that we *want* the notification to happen after
> restartDirScan, in the cases where stopDirScan/restartDirScan is used.

No, we actually have a test that proves that we get to signal after 
restartDirScan is enabled again
  KDirWatch_UnitTest::stopAndRestart
the problem with that test is that it waits 200 ms before restarting the dir 
scan so the problem of the async socket is workarounded.

Cheers,
  Albert

> 
> KDirWatch emits "dirty" for a whole directory, as in
> "the mtime of the dir has changed because *something* has changed in this
> dir".
> 
> So if yo're going to create or delete MANY files in a directory, and you
> still want filemanager views to react, the optimization is to postpone the
> "dirty" until you're done, so that only one dirty signal is emitted instead
> of many. That's what stopDirScan/restartDirScan does [is supposed to do].
> 
> So if you're seeing a single dirty signal after the above sequence, I would
> say it works as advertised.
> 
> On the other hand if you want zero dirty signals emitted, that's what
> removeDir is for.




More information about the Kde-frameworks-devel mailing list