Review Request 118612: Fix KDirWatch's unit tests on certain file system.

[Matthew Dawson]

-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/118612/
-----------------------------------------------------------

(Updated June 13, 2014, 9:57 p.m.)


Status
------

This change has been marked as submitted.


Review request for KDE Frameworks.


Repository: kcoreaddons


Description
-------

When using QFileSystemWatcher, try to avoid having deleted files stop being watched.

When a file is deleted, QFileSystemWatcher does not explicitly signal this fact,
instead emitting a generic changed signal.  However, it will stop watching the file
in question, at least on Linux with the inotify backend.  Normally this is ok, but
if a file is quickly recreated and the inode number is unchanged, KDirWatch assumes
the file is still monitored and no further changes to the file will occur.

Instead, KDirWatch will now always try to re-add the file to QFileSystemWatcher.
It doesn't bother checking if the operation succeeded, as in most cases it will
fail as the file is still watched.  It can only assume the file is now being
watched at this point.


Fix unit tests for KDirWatch when TMPDIR's filesystem reuses inode numbers.

When the filesystem TMPDIR points to (by default /tmp) reuses inode numbers,
the testDeleteAndRecreateFile test will fail as neither the stat nor the
QFileSystemWatcher backends can detect the deletion/recreation as two discrete
events.  They only detect the fact the file changed, and emit the dirty signal.
Fix the test suite to check for this case, and allow the test to proceed.


Diffs
-----

  autotests/kdirwatch_unittest.cpp c3dba4391b8ebcbedeaa53d51f2a170aa5695ccb 
  src/lib/io/kdirwatch.cpp 7da1fdba8cd1a2e6a7d5bf9cef999d50b44ebf99 

Diff: https://git.reviewboard.kde.org/r/118612/diff/


Testing
-------

Unit tests all pass on all four backends (FAM only tested against gamin)


Thanks,

Matthew Dawson

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20140613/39e9f4c3/attachment.html>