KDirWatch problem/bug

Jeroen Wijnhout Jeroen.Wijnhout at kdemail.net
Fri Feb 13 16:23:59 GMT 2004


Hi,

I've been experiencing some annoying behavior of KDirWatch in combination with 
KatePart (used in Kile). Sometimes the removal of a file from KDirWatch 
fails.

This is what happens:

Suppose we save a file (in Kile using KatePart).

In KateDocument::saveFile() the file is removed from the KDirWatch, file is 
saved, then the file is added to KDirWatch again. Perfect, but ..., sometimes 
the removal fails and a dirty signal is emitted (since the file was being 
watched during saving). The consequence of this is that users of Kile get 
presented a pop-up telling them that the file has changed on disk, while this 
is not the case, quite annoying.

I've tracked down at which line the removal fails (I'm using the 
KDE_3_2_BRANCH, but AFAIC there is no difference with HEAD):
kdirwatch.cpp: removeEntry, line 669
  if (e->m_clients.count() || e->m_entries.count())
    return;

Usually e->m_client.count() and e->m_entries.count() are both zero, so the 
function continues and removes the entry. However sometimes 
e->m_clients.count() == 1, e->m_entries.count() == 0
and the function returns, while that shouldn't happen (I've checked that the 
file is still being watched by KDirWatch, so calling removeFile() should 
remove it).

I can reproduce this behaviour, but I haven't figured out what triggers it. At 
the moment all I can say is: Open and close files in Kile at random save a 
file, take focus away from Kile, return and pray the bug shows up (that is if 
you are a developer, users pray for a different result :-) ).

Anybody has any idea what can trigger this bug. And, more importantly, how to 
fix it?

best,
Jeroen

-- 
Kile - an Integrated LaTeX Environment for KDE
http://kile.sourceforge.net




More information about the kde-core-devel mailing list