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