----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/118458/#review59456 -----------------------------------------------------------
This review has been submitted with commit d56f01760138fd8cd2c2a4e09916b65c31891065 by Matthew Dawson to branch master. - Commit Hook On June 4, 2014, 5:05 p.m., Matthew Dawson wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/118458/ > ----------------------------------------------------------- > > (Updated June 4, 2014, 5:05 p.m.) > > > Review request for KDE Frameworks. > > > Bugs: 329802 > https://bugs.kde.org/show_bug.cgi?id=329802 > > > Repository: kcoreaddons > > > Description > ------- > > Fix KDirWatch to act more reliably against various backends. > > - When KDirWatch used a FAM backend, it wouldn't actually wait for the > necessary watches to be put in place before returning, allowing for a race > where an application may think a watch is in place when it really isn't. > This was easily seen using gamin and running the testDeleteAndRecreateFile > test. Fix by delaying useFAM until the watch is in place by waiting until > the EndExist FAM event is received. This adds ~100-200ms per watch with > gamin. > - When a file is deleted and recreated, and scanEntry detects it, the dirty > signal would be emitted. Fix to emit a deleted + created signal, as expected. > - When a deleted signal was requested, other signals were dropped. Due to > the above point, this would stop the created signal from being emitted. Now, > all signals are emitted, even when a delete is detected. > - When watching recreated files, the created signal could get lost as there > was a race between when the created signal would be generated and its signal > spy would be created. Fix by making sure the spy is created before the signal > could be emitted. > - Make sure the created signal isn't emitted twice with both FAM and the > polling timer. This occurs as FAM doesn't fix up the fact the entry has been > created, and the poller thus assumes it needs to notify the world. Fix by > having FAM not emit the event in this case. > > BUG: 329802 > > Note that due to a bug in the FAM daemon (which doesn't exist in the gamin > daemon), the testDeleteAndRecreateDir unit test fails as FAM doesn't detect > the folder deletion. This test previously passed due to the race condition > outlined in bug 329802, which was fixed in this RR. I've confirmed this is a > bug in FAM using a minimal program talking directly to the daemon, and > watching the strace output from FAM. FAM doesn't detect when a folder it is > watching directly is deleted. It does detect when a folder inside a folder > it is watching is deleted, however. > I think this should go in as is, as the unit test failing exposes the actual > problem, instead of hiding behind a race when it doesn't really work. If > running against FAM is important, I can see about tracking down the issue. > > > Diffs > ----- > > autotests/kdirwatch_unittest.cpp 4e638e089012276dc8b17b9d960732a161cc3be1 > src/lib/io/kdirwatch.cpp cc6feec4d2b2598e50c853172bbc295a8c719bc2 > src/lib/io/kdirwatch_p.h cf63c41745091cfedcf1b27c9e4aa77d3db6b31a > > Diff: https://git.reviewboard.kde.org/r/118458/diff/ > > > Testing > ------- > > Unit tests all pass now with gamin. Using FAM, one test fails as described > above, but I've confirmed the daemon itself is causing the issue. > > > Thanks, > > Matthew Dawson > >
_______________________________________________ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
