KDirWatch issue

[Albert Astals Cid]

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.
> 
> > Well, it does.
> > I've attached a small test.
> 
> Yeah :/
> 
> > When I modify the code and use stopScan() ... create ... startScan()
> > I still receive the dirty signal with the path to the file I created.
> 
> stopScan and startScan are just shorthand for stopDirScan and restartDirScan
> for every dir, so that is why it behaves the same, because it's really the
> same code.
> 
> > Only way it works without signal is
> > removeDir(dir) ... create ... addDir(dir)
> > 
> > Is this how it's supposed to work ?
> 
> The problem is at the moment the flow is like this
>  * Stop scanning
>  * Create File
>  * Restart scanning
>  * inotify socket gets notified of changes, since you already restarted the
> scanning, you get notified
> 
> 
> The only thing i can think of we could do to fix this is manually read from
> the socket when stopping/restarting the scan so that things get triggered in
> order, but after doing that it still doesn't work as expected.
> 
> 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.
> 
> So I tried finding why we have these two methods that do the same thing but
> in different ways, and sadly I couldn't find enough info in the git
> history.
> 
> My guess is that it may be because at some point it was thought that
> stopDirScan would be more efficient than removeDir.
> 
> Given that stopDirScan doesn't work, is not unit tested 

Wrong wording here, stopDirScan is unit tested, but doesn't test the full 
behaviour.

Cheers,
  Albert

> and actually almost
> noone uses it
>   https://lxr.kde.org/search?_string=stopDirScan
> my suggestion is to simply mark stopDirScan as deprecated and make it call
> removeDir
> 
> Opinions?
> 
> Cheers,
>   Albert