[Nepomuk] Review Request: Fix bug 286854 (Dolphin loses metadata when moving files)

[Simeon Bird]

-----------------------------------------------------------
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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/nepomuk/attachments/20121109/930028da/attachment.html>