rkflx added a comment.
After further analysis, I can draw these conclusions (contradicting some
assumptions from above, confirming others):
1. KDirWatch correctly emits at least one "dirty" each for directory watches
when files are created, modified, deleted or moved_to (i.e., KDirWatch is not
the reason for the bug).
2. The directory code path in Okular only works for deleted files, but never
works for moved files (that's the real reason for the bug).
3. The file code path in Okular would work, if KDirWatch emitted dirty for a
file on move_to (but KDirWatch does not and should not).
This can be shown as follows (separately for each conclusion):
1. From kcoreaddons git repo, run `kdirwatchtest_gui` and observe the
dirwatch "Dirty (w1)", double check with `inotifywait -m .`:
- `touch x` → 1 observation with reported path set to "x" (attrib and
close_write in one), 2 observations for "/" (1 create, for some reason
resulting in 2 dirty emissions)
- `touch x` (again) → 1 observation for "x" (attrib and close_write in one)
- `rm x` → 1 observation for "/" (delete)
- `touch ../x && mv ../x x` → 2 observations for "/" (moved_to, 2 emissions
for some reason)
- `touch ../x && mv ../x x` (again) → 2 observations for "/" (moved_to, 2
emissions for some reason)
2. Set a breakpoint after `// Our parent has been dirtified`, open x.txt in
Okular, issue `touch ../x && mv ../x x.txt` and step through the code block.
Notice how the breakpoint is passed two times (see above), in both cases
`m_fileWasRemoved` is not being set to true (as the file still `::exists`),
resulting in skipping `m_dirtyHandler->start` even though the file `::exists`
here too. IOW, no matter what triggers the directory watch, Okular uses a Qt
function to check for file deletion which correctly reports the file still
being there, so a reload is never triggered.
3. Apply https://phabricator.kde.org/D7671 and remove the directory watcher
to simulate "dirty" on move_to for files. `touch ../x && mv ../x x.txt`
triggers reload of x.txt in Okular.
Therefore, the only thing left to clarify in the docs for KDirWatch is the
behaviour on move. E.g., currently for file watches a move_to results in
"created" and "deleted", but not "dirty" (could be made more explicit). As the
rest of the discussion is not Okular specific anymore, let's continue on
kde-frameworks-devel.
REPOSITORY
R223 Okular
REVISION DETAIL
https://phabricator.kde.org/D7671
To: progwolff, aacid
Cc: sander, rkflx, #okular, aacid
