KDirWatch and files that are removed/created

Julian Wolff wolff at julianwolff.de
Thu Sep 7 11:50:59 UTC 2017


On Thu Aug 31 21:00:06 UTC 2017 Albert Astals Cid wrote:
>
>Okular is watching the file 
>	"/home/kdeunstable/breeze-icons/README.md"
>and its parent folder
>	"/home/kdeunstable/breeze-icons"
>that is being edited by kate, when you save in kate, this is what Okular sees 
>coming from KDirWatch
>
>	dirty "/home/kdeunstable/breeze-icons"
>	dirty "/home/kdeunstable/breeze-icons/.README.md.kate-swp"
>	dirty "/home/kdeunstable/breeze-icons/README.md.kn7048"
>	dirty "/home/kdeunstable/breeze-icons"
>	deleted "/home/kdeunstable/breeze-icons/README.md"
>	created "/home/kdeunstable/breeze-icons/README.md"
>
>
>Given that I'm also watching "/home/kdeunstable/breeze-icons" I was expecting 
>that i would get
>
>	dirty "/home/kdeunstable/breeze-icons"
>	dirty "/home/kdeunstable/breeze-icons/.README.md.kate-swp"
>	dirty "/home/kdeunstable/breeze-icons/README.md.kn7048"
>	dirty "/home/kdeunstable/breeze-icons"
>	deleted "/home/kdeunstable/breeze-icons/README.md"
>	dirty "/home/kdeunstable/breeze-icons"
>	created "/home/kdeunstable/breeze-icons/README.md"
>	dirty "/home/kdeunstable/breeze-icons"
>
>Am i expecting wrong?
>
>Cheers,
>  Albert
>
>P.S: Okular has code that expects it to work like the second case, so i think 
>at some point in the past that is what happened, though i compiled the old 
>kdelibs4 verison and I don't get that either.

In https://phabricator.kde.org/D7671 Albert and I had a discussion about the 
behaviour of KDirWatch.

To me the behaviour seems reasonable, but it is indisputable a little 
confusing and the docs are not very clear.

For example, the documentation does not mention the MOVE_TO and MOVE_FROM 
signals that are handled internally by the inotify backend. "created" and 
"deleted" signals are sent when files are moved, though no files are actually 
created or deleted. 
The "dirty" signal of the corresponding directory is not emitted when files 
are moved, yet the docs say that a directory gets dirty when files are deleted 
or created. Does the dirty signal depend on actually created/deleted files or 
on the created/deleted signals of the file?
 
The docs only name the cases of modified and created/deleted files.
But there are several more cases that need to be considered individually.

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

    What happens on `rm watchedfile && touch watchedfile`? 
        Is the directory dirty now?
        What signals are emitted in which order?
        Is the file still being watched?

    What happens on `mv somefile watchedfile`?
        Is watchedfile dirty now?
        Is the directory dirty now?
        What signals are emitted?
        Is the file still being watched?

    What happens on `mv watchedfile somefile`?
        Is somefile dirty now?
        Is watchedfile still watched, though it does not exist anymore?

    What happens on `mv watchedfile somefile && touch watchedfile`?

Is there anyone who feels responsable for this?
I think the intended behaviour of KDirWatch should be specified somehow, so we 
can better argue if the actual behaviour is correct or not.
The docs should be reworked and maybe extended by some examples.

Cheers,
    Julian


More information about the Kde-frameworks-devel mailing list