KDirWatch issue

[David Faure]

On lundi 8 mai 2017 17:51:06 CEST Albert Astals Cid wrote:
> El dilluns, 8 de maig de 2017, a les 17:32:35 CEST, David Faure va escriure:
> > On lundi 8 mai 2017 16:14:47 CEST Albert Astals Cid wrote:
> > > > 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
> > 
> > That's what I'm saying yes. We want the notification to happen, and it
> > happens.
> 
> Sorry, typo, "to signal" is "no signal", since you don't want to open the
> test i'll copy the code here

Ah sorry. I didn't see the need to read the test since I was agreeing with 
your sentence due to the typo ;)

> QCOMPARE(spyDirty.count(), 0); // as documented by restartDirScan: no signal

OK, the docu says we expect the app to have taken care of updating the view
by other means.

We could re-evaluate this, but...

The use of restartDirScan in KIO (CopyJob and DeleteJob) actually does NOT 
need restartDirScan to emit anything, since CopyJob takes care of notifying 
about changes using DBus (KDirNotify).
Additional signals would just slow things down. In fact this is the only 
reason why KIO uses restartDirScan in the first place.

The fact that inotify breaks that is therefore a bug in my view.
i.e. I agree with the original post.

The question is whether it's fixable...

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