KDirWatch problem/bug

Andras Mantia amantia at kde.org
Fri Feb 13 17:17:33 GMT 2004


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I can confirm the same bug for Quanta, and there are many bugreports (reported 
on bugs.kde.org and in private mails). Some users were using NFS, others FAM, 
others said that the problem might be triggered if there are accented chars 
in the document and so. I planed to investigate the problem in the following 
days and I'm partly sad, partly happy to see that it's not my only problem.  
Actually I do the following:
- - every opened document is added to KDirWatch
- - during some operations performed by Quanta, I remove the file and readd 
later to the KDirWatch
- - users see problem either during the operation done by Quanta or when they 
save a file. During save only the Kate's save method is called as in case of 
Kile. 

Here are some bug number: 75044, 74305, 74217 (this might be interesting). 

I'd say I couldn't reproduce the problem yet, and I'm using 2.4.20, dnotify 
(no fam) and no nfs.

Andras

On Friday 13 February 2004 18:23, Jeroen Wijnhout wrote:
> 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

- -- 
Quanta Plus developer - http://quanta.sourceforge.net
K Desktop Environment - http://www.kde.org
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2-rc1-SuSE (GNU/Linux)

iD8DBQFALQatTQdfac6L/08RAp2SAJ0bN/C7nbM9csp1+EFv5uV/87NbYgCfTHFC
riSjDei2W+n8mEOk1qtiweg=
=H6hb
-----END PGP SIGNATURE-----




More information about the kde-core-devel mailing list