Bug 119341

Summary:	KDirWatch stopDirScan affects outside KDirWatch instances also - signal missing
Product:	[Unmaintained] kio	Reporter:	Dirk Stoecker <kde>
Component:	general	Assignee:	David Faure <faure>
Status:	RESOLVED FIXED
Severity:	normal
Priority:	NOR
Version First Reported In:	unspecified
Target Milestone:	---
Platform:	Unlisted Binaries
OS:	Linux
Latest Commit:		Version Fixed/Implemented In:
Sentry Crash Report:
Attachments:	The testcase C File. The testcase H-File.

Description Dirk Stoecker 2006-01-01 17:47:47 UTC

Version:            (using KDE KDE 3.5.0)
Installed from:    Unspecified Linux

When multiple instances of KDirWatch are used in one program, then a call to stopDirScan() affects all the other instances watching the same directory. They don't get the dirty signal.

The order of emitted signal seems to be equal to the order of addDir() calls. This means the first instance, which calls an addDir for an directory will see the dirty() signal. If it does a stopDirScan() in it's signal slot, then all the following instances will not get dirty().

I will attach a example program illustrating this behaviour. If #define NOERROR is used, then the 3 top LineEdits will show a difference whenever you click on the delete/new buttons. You will see the new/deleted file in the listview.

If NOERROR is not defined, then only Test1 and 2 will react. Test3 never gets a dirty() signal.

Comment 1 Dirk Stoecker 2006-01-01 17:48:26 UTC

Created attachment 14097 [details]
The testcase C File.

Comment 2 Dirk Stoecker 2006-01-01 17:48:59 UTC

Created attachment 14098 [details]
The testcase H-File.

Comment 3 Dirk Stoecker 2006-01-10 18:52:52 UTC

Would be nice to hear something about this. It took me 3 days to compile the bug report and the problem is really annoying in the application I extracted the report from.

Comment 4 David Faure 2006-01-10 22:14:08 UTC

SVN commit 496601 by dfaure:

Use re-entrant iteration so that stopDirScan/restartDirScan from a slot connected
to one of our signals, doesn't break receiving the signal in other instances of KDirWatch.
Thanks to Dirk Stoecker <kde dstoecker.de> for his great testcase.
BUG: 119341


 M  +5 -2      kdirwatch.cpp  


--- branches/KDE/3.5/kdelibs/kio/kio/kdirwatch.cpp #496600:496601
@@ -1220,8 +1220,11 @@
 #endif
   }
 
-  Client* c = e->m_clients.first();
-  for(;c;c=e->m_clients.next()) {
+  QPtrListIterator<Client> cit( e->m_clients );
+  for ( ; cit.current(); ++cit )
+  {
+    Client* c = cit.current();
+
     if (c->instance==0 || c->count==0) continue;
 
     if (c->watchingStopped) {

Comment 5 David Faure 2006-01-10 22:45:14 UTC

Do you agree with your test program being licensed under the LGPL and added to kdelibs/kio/tests?
(with a better naming for the files;)
I'd like to keep it around, not only for this bug.
(I just tested it on KDE4/Qt4 too, it only needed s/KMainWindow/QWidget/ since kmainwindow already has a layout.)
Thanks.

Comment 6 Dirk Stoecker 2006-01-11 08:59:53 UTC

It is public domain. Do with it whatever you want.

Well, the layout warning was on QT3 as well, but I did not figure out, how to fix it :-) And I didn't want to spend more time than necessary on a test tool.

Comment 7 David Faure 2006-01-11 11:25:06 UTC

On Wednesday 11 January 2006 08:59, Dirk Stoecker wrote:
> Well, the layout warning was on QT3 as well, but I did not figure out, how to fix it :-) And I didn't want to spend more time than necessary on a test tool.


Sure - it's just that in QT4 Q_ASSERT is fatal so I had to fix this problem before the program would start ;-)