On Friday 29 November 2002 18:26, Manuel Amador wrote:
> El jue, 28-11-2002 a las 18:06, Michael Kreitzer escribi=C3=B3:
> > 'cause it all starts when I click on the shortcuts on my desktop that=
 are
> > URL's for either sftp connections or smb connections.  That's when th=
e
> > fam binary itself starts using 100% CPU... I don't kno wmuch about kd=
e's
> > architecture so I'm sure it could be something else... I'm just fishi=
ng
> > for answers.
>
> and it enters a strange tight loop.  All applications which are
> subscribed to the fam instance experiment odd behavior meanwhile.  I
> disabled fam for that reason.
>
> But what bothers me is that, if I do dd if=3D/dev/zero of=3Dfile, and I=
 have
> a konqueror window open, fam provokes a situation in konqueror, where
> konqueror updates a zillion times.  FAM should send update events to
> konqueror at a reasonable pace (half a second maybe?)!  Or maybe the

See other mail. Configure FAM to only use STAT.

> subscribing application should be able to tell it how often it needs to
> know about updates (And the default should still be half a second).

Half a second is way to much when the only solution possible is polling o=
ver=20
NFS. The application would need to check for remote mounts (OK, KDirWatch=
=20
already does this). Better let a tool like FAM decide on this.
Aside from that, an application usually always wants events "as fast as=20
possible". So there's no need for applications to specify any time interv=
als.=20
Using a kernel service like dnotify, the make the sense at all.

> And FAM also causes unmountable removable devices.   Even when I've
> closed all Nautilus/Konqueror windows, I can't eject/unmount media
> because FAM insists on keeping track of files in it to see if they've
> changed.  Absurd! FAM should let go when an unmount is triggered by the

That shouldn't happen. When you kill applications doing file watching wit=
h=20
FAM, FAM will see the broken IPC and finish watching of all files for tha=
t=20
application: for dnotify, this means closing the corresponding files. The=
=20
watching app can be *every* KDE application using a KFileDialog, for exam=
ple.=20
So better shut down KDE :-)

> user/system.  On Mandrake, which has supermount, FAM causes horrible
> CD-ROM errors (you eject the CD, CD is gulped again, if you manage to
> snatch it before the drive closes, you still have /mnt/cdrom listing
> files from the CD-ROM which isn't even there anymore).

Hmm. Does a STAT of files in unmounted directories make supermount to do =
a=20
mount?
That's bad. This is a problem with KDirWatch (without FAM), too.
So KDE *needs* to be aware of unmounting?
Should we supply an "umount" wrapper with KDE doing a DCOP broadcast?

Josef

>
> luck,
>
> >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to
> >> unsubscribe <<

 
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<