[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-devel
Subject:    Re: FAM and 3.1rc3
From:       Manuel Amador <amadorm () usm ! edu ! ec>
Date:       2002-11-29 23:40:20
[Download RAW message or body]


> 
> See other mail. Configure FAM to only use STAT.

that will stop FAM from firing update events astray?

> 
> Half a second is way to much when the only solution possible is polling over 
> NFS.

well, yes =)

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

Odd.  lsof'ing shows FAM with CD-ROM files open

> > 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 
> 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?
no.  This is a FAM problem.  FAM shouldn't block umounting drives,
ever.  Its purpose is to notify file change, and EVIDENTLY a file
disappearing because of an umount is a VALID change, in the eyes of
client applications.

BTW, how does FAM handle security? It just lets anyone ask for a file
watch?

luck,

 
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
[prev in list] [next in list] [prev in thread] [next in thread]