[PATCH] fix #47996

[Michael Brade]

On Thursday 07 November 2002 14:01, Josef Weidendorfer wrote:
> On Thursday 07 November 2002 12:58, David Faure wrote:
> > IMHO we need this fix, whichever way it's done for 3.1.
> > If your KDirLister change works :), I suggest you go ahead and commit it.
>
> Yes. Commit it please.
Done.

> I think I have enough time to implement the "watchFiles" and "recursive"
> flags for KDirWatch::addDir() for KDE 3.2, as well as the event merging and
> emitting. This HAS to be done in KDirWatch.
Ok, good to know.

> But if you commit your changes, I want feel that forced to implement it for
> KDE 3.1 ;-)
:-)

> BTW, why do you get that many events from FAM? I don't understand it.
Me neither ;) Well, it happens if I download a big file (20 MB for example) 
from the internet. I have a 10 MBit connection, so the data is coming fast 
and FAM seems to think it has to emit an event for every byte written... I 
can't even take advantage of the full 10 MBit with Konqy because of my CPU 
being at 100% already when receiving roughly 300kB/s. With ncftp I get 
800kB/s.

> Of course when a program writes a large file, and DNOTIFY is used in FAM,
> you will get a signal for every write() system call for that file :-(
I see.

> Regarding the little number of signals in KDirWatch:
> I don't feel guilty. When I introduced explicit file watching before KDE
> 3.0, I added separate signals. Short before the KDE 3 API freeze it was
> decided to unify the signals for simplified usage. 
I know. IIRC it was me who suggested to reduce the number of signals... at 
that time I didn't know about the possibility of being flooded with events.

> For KDE 4: Do you think it has an advantage to have a "fileExists" signal,
> emitted for all existing files in a directory after a addDir() ?
Hmm. What do you mean with fileExists? My problem ATM is that with STAT I get 
a signal for a directory registered with addDir which means "a file in this 
directory was changed", so I need to rescan the whole directory. When using 
FAM I get the same signal, however, now it means "exactly this file has 
changed".

> I get these from FAM, and once "watchFiles" is implemented, it is easy to
> generate the signals in STAT/DNOTIFY mode, too.
Sounds good, however, not really important once KDirWatch emits less signals 
because then it's no problem to do two QDict lookups per signal.

And to answer you other mail: it's not neccessary to have _6_ signals, 
created() can emit a directory or a file, not important at all. For deleted() 
it may be nice to know if it is a directory or not, but not too important 
either. This simply doesn't happen really often.

-- 
Michael Brade;                 KDE Developer, Student of Computer Science
  |-mail: echo brade !#|tr -d "c oh"|s\e\d 's/e/\@/2;s/$/.org/;s/bra/k/2'
  °--web: http://www.kde.org/people/michaelb.html

KDE 3: The Next Generation in Desktop Experience

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: signature
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20021107/8e4c57cf/attachment.sig>