KDirWatch bug and the analysis. Help is welcome!

[David Faure]

On Thursday 01 August 2013 01:30:08 Mark wrote:
> 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.

OK. First let's imagine that it's not a hidden file. Say you create "foo" file 
(from the command line) in a directory currently shown in dolphin.
When using inotify, we could get a "foo was created" signal, but then what? 
KDirLister is going to need more details anyway (size, mimetype, date, icon, 
etc.). To get that, it re-lists the directory. Don't say it could just 
KIO::stat the new file, it becomes very slow if many files get 
created/modified, and it creates much more complex code paths in kdirlister 
which is already complex (it would also need to handle deletion separately). 
Instead we have a single reaction to "something changed in this directory" : 
re-list it and update it to show the changes (after basically diff'ing the new 
listing and the old listing).

The other reason why things work that way is that inotify isn't available 
everywhere. On systems without inotify, all we have is a regular stat() on the 
directory. So when anything changes in the directory, all we get from 
KDirWatch is "something changed", no details => relist.
There's another technology available, FAM, but IIRC it gives us the same 
(directory-level signal).

We could, however, fix this by filtering out hidden files ("dot files") in the 
KDirWatch inotify event handling, optionally. (since this depends on whether 
the kdirlister is showing hidden files or not). But with care in case multiple 
kdirwatch clients specify a different value for the "notify for hidden files" 
new flag, for the same directory. Feel free to look into that.

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