KDirWatch issue

[David Faure]

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.

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.

-- 
David Faure, faure at kde.org, http://www.davidfaure.fr
Working on KDE Frameworks 5