KDirWatch bug and the analysis. Help is welcome!

Mark markg85 at gmail.com
Thu Aug 1 00:30:08 BST 2013


On Thu, Aug 1, 2013 at 12:25 AM, Milian Wolff <mail at 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 explain a
> > lot in this mail. Please read it very carefully.
>
> <snip>
>
> > 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 at milianw.de
> http://milianw.de
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20130801/04e5e907/attachment.htm>


More information about the kde-core-devel mailing list