Remove m_recentlyFinishedRequests from the metadatamover.
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 840dbb60 in 2009, to prevent events received twice from being acted on twice. However, it means that if an event is repeated quickly, the repeat will not be acted on, even if it should. (eg, move A -> B -> A -> B in quick succession) Nowadays we just use inotifty, which, so far as I know, cannot deliver the same event twice. and so we can just remove the list entirely. In other words: bug 286854 is due to a rogue, no longer needed, workaround. BUG: 286854 FIXED-IN: 4.10 REVIEW: 107260