KDirWatch and files that are removed/created

[Henrik Fehlauer]

Thanks for keeping on top of this, Julian. Here are my findings:

On Thursday 07 September 2017, Julian Wolff wrote:
> The "dirty" signal of the corresponding directory is not emitted when files are moved

That's not what I see when testing with kdirwatchtest_gui. I get dirty signals for all three possible cases (move out of dir → 1, move into dir → 2, move around inside dir → 2).

> Assuming we watch a directory and also a single file in this directory.

Let's start with looking at directory and file watches separately (those are confusing enough), combining both should only be the second step.

> Is there anyone who feels responsable for this?

"git log kcoreaddons/src/lib/io/kdirwatch*" suggests @dfaure still cares now and then.

> I think the intended behaviour of KDirWatch should be specified somehow

Rethinking this from scratch is probably a lot of work. Why not simply test the current behaviour and document that in terms of "move"? If there are inconsistencies, those should be discussed and fixed, of course. Did you look into existing autotests or try writing new ones to jump start this?

> The docs should be reworked and maybe extended by some examples.

In addition to documenting the behaviour for directory and file watches regarding "move", there could be a note mentioning QSaveFile as an example for the technique of atomic move semantics (as already stated in Phabricator, it is a common gotcha that watching "dirty" is not enough).

For less "should be" and more "will do", I can try to help with this once we know what's the intended behaviour.

Cheers
Henrik