Bug 119341 - KDirWatch stopDirScan affects outside KDirWatch instances also - signal missing
Summary: KDirWatch stopDirScan affects outside KDirWatch instances also - signal missing
Status: RESOLVED FIXED
Alias: None
Product: kio
Classification: Unmaintained
Component: general (show other bugs)
Version: unspecified
Platform: Unlisted Binaries Linux
: NOR normal
Target Milestone: ---
Assignee: David Faure
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2006-01-01 17:47 UTC by Dirk Stoecker
Modified: 2006-01-11 11:25 UTC (History)
0 users

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:


Attachments
The testcase C File. (2.95 KB, text/x-c++src)
2006-01-01 17:48 UTC, Dirk Stoecker
Details
The testcase H-File. (532 bytes, text/x-c++hdr)
2006-01-01 17:48 UTC, Dirk Stoecker
Details

Note You need to log in before you can comment on or make changes to this bug.
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 ;-)