From kde-core-devel Wed Jul 31 23:30:08 2013 From: Mark Date: Wed, 31 Jul 2013 23:30:08 +0000 To: kde-core-devel Subject: Re: KDirWatch bug and the analysis. Help is welcome! Message-Id: X-MARC-Message: https://marc.info/?l=kde-core-devel&m=137531345502290 MIME-Version: 1 Content-Type: multipart/mixed; boundary="--047d7b343b3a5e44d804e2d71cbe" --047d7b343b3a5e44d804e2d71cbe Content-Type: text/plain; charset=ISO-8859-1 On Thu, Aug 1, 2013 at 12:25 AM, Milian Wolff wrote: > On Wednesday 31 July 2013 20:51:11 Mark wrote: > > Hi, > > > > I'm horrible in clearly explaining issues and i'm going to explain a > > lot in this mail. Please read it very carefully. > > > > > Subsequent signals (even create, delete or anything besides dirty) is > > following this same path where the emit is being triggered from > > KDirWatchPrivate::slotRescan in the above mentioned snippet. All > > signals are thus being send as dirty signals! For more clarity, this > > is what KDirLister(Cache) actually receives (in > > KDirListerCache::slotFileDirty) as signals for the same folder: > > (DIRTY signal) /home/mark/massive_files > > (DIRTY signal) /home/mark/massive_files/.directory.lock > > (DIRTY signal) /home/mark/massive_files/.directorym13357.new > > (DIRTY signal) /home/mark/massive_files (yes, it starts with this and > > ends with this) > > > > Now i'm guessing this isn't right. All dirty signals of which two(!!) > > are my main folder. > > Besides that it's two times that signal, imo this is what should be done. > Creating/Removing a file makes its parent folder dirty. > > If that needs to happen then there is no change needed since that is currently happening which i think is a bug. If there is no way to detect which files inside a directory have been created/added/modified then it indeed is best to just mark the whole directory as dirty thus cause a complete re-scan. That is what happens now. However, we have been given the power of inotify which gives more detailed signals and lets us know which files have been created/added/modified which we should be used imho. > Maybe KDirListerCache should not listen on dirty but rather on created and > deleted instead, which should come with the semantics you describe? > The dirty signal handling is not wrong, the signals it gets are. it's receiving a signal to many that already causes a full re-scan. It would probably be fine if it just received the signals that inotify is broadcasting: (CREATE signal) /home/mark/massive_folder/.directory.lock (MODIFY signal) /home/mark/massive_folder/.directory.lock (CREATE signal) /home/mark/massive_folder/.directoryc13357.new (MODIFY signal) /home/mark/massive_folder/.directoryc13357.new (DELETE signal) /home/mark/massive_folder/.directoryc13357.new (CREATE signal) /home/mark/massive_folder/.directory (DELETE signal) /home/mark/massive_folder/.directory.lock > Bye > -- > Milian Wolff > mail@milianw.de > http://milianw.de > --047d7b343b3a5e44d804e2d71cbe Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

= On Thu, Aug 1, 2013 at 12:25 AM, Milian Wolff <mail@milianw.de> wrote:
On Wednesday 31 July 2013 20:51:11 Mark = wrote:
> Hi,
>
> I'm horrible in clearly explaining issues and i'm going to exp= lain a
> lot in this mail. Please read it very carefully.

<snip>

> Subsequent signals (even create, delete or anything besides dirty) is<= br> > following this same path where the emit is being triggered from
> KDirWatchPrivate::slotRescan in the above mentioned snippet. All
> signals are thus being send as dirty signals! For more clarity, this > is what KDirLister(Cache) actually receives (in
> KDirListerCache::slotFileDirty) as signals for the same folder:
> (DIRTY signal) /home/mark/massive_files
> (DIRTY signal) /home/mark/massive_files/.directory.lock
> (DIRTY signal) /home/mark/massive_files/.directorym13357.new
> (DIRTY signal) /home/mark/massive_files (yes, it starts with this and<= br> > ends with this)
>
> Now i'm guessing this isn't right. All dirty signals of which = two(!!)
> are my main folder.

Besides that it's two times that signal, imo this is what should = be done.
Creating/Removing a file makes its parent folder dirty.

If that needs to happen then there is no change neede= d since that is currently happening which i think is a bug.
If th= ere is no way to detect which files inside a directory have been created/ad= ded/modified then it indeed is best to just mark the whole directory as dir= ty thus cause a complete re-scan. That is what happens now.

However, we have been given the power of inotify which = gives more detailed signals and lets us know which files have been created/= added/modified which we should be used imho.
=A0
Maybe KDirListerCache should not listen on dirty but rather on created and<= br> deleted instead, which should come with the semantics you describe?

The dirty signal handling is not wrong, the si= gnals it gets are. it's receiving a signal to many that already causes = a full re-scan. It would probably be fine if it just received the signals t= hat inotify is broadcasting:

(CREATE signal) /home/mark/massive_folder/.directory.lock
(MODIFY signal)= /home/mark/massive_folder/.directory.lock
(CREATE signal)= /home/mark/massive_folder/.directoryc13357.new
(MODIFY signal)= /home/mark/massive_folder/.directoryc13357.new
(DELETE signal)= /home/mark/massive_folder/.directoryc13357.new
(CREATE signal)= /home/mark/massive_folder/.directory
(DELETE signal)= /home/mark/massive_folder/.directory.lock

=

Bye
--
Milian Wolff
mail@milianw.de
http://milianw.de

--047d7b343b3a5e44d804e2d71cbe--