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