-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/107260/
-----------------------------------------------------------
Review request for Nepomuk, Vishesh Handa and Sebastian Trueg.
Description
-------
Bug 286854 seems to be due to an old, no longer needed, rogue workaround.
This patch removes the workaround.
The filewatch service calls moveFileMetadata ( oldPath, newPath).
This sticks the metadata move into a queue, like so:
if ( !m_updateQueue.contains( req ) && !m_recentlyFinishedRequests.contains(
req ) )
m_updateQueue.enqueue( req );
If you move oldPath to newPath twice in fairly quick succession, the first move
will
still be in the m_recentlyFinishedRequests, and the metadata move will not be
queued.
git blame tells me that trueg added this check with commit 840dbb6005ead in
2009.
He explained why in this comment:
// we use several systems to watch for file operations.
// Thus, we can get the same request more than once. We then
// need a way to determine if we have already handled it.
// (otherwise we would remove the previously moved data.)
// The only way to do that is to keep a list of all requests
// that have been handled in the last N seconds.
So far as I know, inotify cannot deliver the same event twice, and so this is
no longer true.
So we can fix the bug by just deleting all code related to the
recentlyFinishedRequests list.
This addresses bug 286854.
http://bugs.kde.org/show_bug.cgi?id=286854
Diffs
-----
services/filewatch/metadatamover.h 47ef497
services/filewatch/metadatamover.cpp 468e74e
Diff: http://git.reviewboard.kde.org/r/107260/diff/
Testing
-------
Compiled, verified that it did indeed fix the bug.
Thanks,
Simeon Bird
_______________________________________________
Nepomuk mailing list
[email protected]
https://mail.kde.org/mailman/listinfo/nepomuk
