KDirWatch problem/bug
Jeroen Wijnhout
Jeroen.Wijnhout at kdemail.net
Sat Feb 14 14:48:14 GMT 2004
On Friday 13 February 2004 22:37, Josef Weidendorfer wrote:
> Am Friday 13 February 2004 17:23 schrieb Jeroen Wijnhout:
> > e->m_clients.count() == 1, e->m_entries.count() == 0
> > and the function returns, while that shouldn't happen (I've checked that
>
> Hmm...
> If e->m_clients.count() == 1 in that line, the file was watched twice
> before, or the wrong KDirWatch object has requested file removal, i.e. not
> the one which added it for watching.
> So the code at this point seems to be correct (Note that m_entries is
> always empty for files; for directories, it contains entries of files/dirs
> being watched in this directory).
>
> The question is, why it is being watched twice.
Ok, this is helpful, now I know what to look for.
> It would be interesting to see which client is still watching the file by
> calling KDirWatch::statistics(). Can you try to reproduce the bug and give
> the output of statistics() ?
>
> > I can reproduce this behaviour, but I haven't figured out what triggers
> > it.
>
> Very good (the reproducability). I tried but wasn't able to trigger this.
I'm quite sure now what is triggering this bug.
If a Kate::Document is closed via closeURL() (the proper way), the file is
removed from the KDirWatch. However if you close it by deleting the
Kate::Document, the file isn't removed from the KDirWatch. Then if you open
the file again, the file is added again to the KDirWatch list. It is being
watched twice now (2 clients).
In Kile it is now easy to work around this situation, just use closeURL()
always. Of course, this is what Kile does typically, but there are some
occasions where Kile opens the file in the background (without creating a
view) and closes it by deleting the document (because closeURL() could
trigger some user interaction, which was unwanted because the user didn't
request to open this file in the first place).
However, if you look at the debug info it seems that the file was being
watched by the same _client_ twice. Doesn't that mean that if this client
requests to remove the file from KDirWatch that is really should do that,
remove it. Now it doens't remove it if e->m_clients.count() != 0. However it
_should_ remove it when all the clients are really one and the same client,
or am I completely wrong?
Anyway, I've attached a short and annotated log file, with the relevant debug
info. I'm not sure where to fix this bug, Kile, Kate or KDirWatch?
best,
Jeroen
--
Kile - an Integrated LaTeX Environment for KDE
http://kile.sourceforge.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: kdirwatch_bug_short.log
Type: text/x-log
Size: 1939 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20040214/e1753835/attachment.bin>
More information about the kde-core-devel
mailing list