problem with KIO::NetAccess and KDirLister/KFileTreeView

[David Faure]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Tuesday 08 October 2002 01:33, Josef Weidendorfer wrote:
> Hi,
> 
> I did some large hacking on KDirWatch before release of KDE 3.0...
> So I feel kind of responsible for this class ;-)
> 
> And relying on KDirWatch should be no problem at all. What are
> the exact issues?
> 
> One problem perhaps is that KDirWatch triggers to often
> when a file is written to in short parts over a longer period of time,

Yes that's a big problem, when FAM is enabled.
I tested copying an image over an other (when fixing that "it should update
the preview" bug), and I got TONS of FAM events (FileChanged),
so the code would keep stopping and relaunching the preview, making the whole
thing quite slow. Some buffering is needed, and IMHO the best would be to do
that buffering in KDirWatch itself (delaying and compressing the events).
Even better would be to have a way to know when the operation (the copying, 
from a terminal) is finished, but I guess that's not possible ;)

> > > kio (KDirWatch): KDirWatch-1 stopped scanning
> > > /home/kf/.kde/share/apps/ScanImages/OCR (now  0 watchers)
> > > kio (KDirWatch): KDirWatch-1 restarted scanning
> > > /home/kf/.kde/share/apps/ScanImages/OCR (now 1 watchers)
> >
> > Any idea what's the reason for this? Could it be that the new file isn't
> > noticed because of this? (either because it happens between those two
> > things, or because the "stopped scanning" drops all pending events).
> 
> Pending events should never be trashed.
> Which app does this stopping/restarting of a DirWatch? This should
> almost never be needed...

I guess this is done by KDirLister (which sort of "quits" the dir, and then "re-enters" it).
Some kdBacktrace() investigation by Klaas would help ;)

> > (Please understand that I'm more familiar with KDirLister and KIO than
> > with KDirWatch itself).
> 
> Feel free to ask ;-)

Well I get a random crash in KDirWatch, which I haven't been able to understand yet,
due to its non-reproduceable nature... It mostly affects KMail (probably: any app using KFileDialog
as the only KDirWatch/KDirLister client), and the crash always looks like this:
#0  0x40feed42 in QGList::next (this=0x8997da4) at /mnt/devel/kde/kdecvs/qt-copy/src/tools/qglist.cpp:858
858             if ( curNode->next ) {
(gdb) bt
#0  0x40feed42 in QGList::next (this=0x8997da4) at /mnt/devel/kde/kdecvs/qt-copy/src/tools/qglist.cpp:858
#1  0x4059215f in QPtrList<KDirWatchPrivate::Client>::next (this=0x8997da4)
    at /mnt/devel/kde/kdecvs/qt-copy/include/qptrlist.h:94
#2  0x404d842b in KDirWatchPrivate::emitEvent (this=0x8822d08, e=0x8997d90, event=2, fileName=@0xbfffed70)
    at /mnt/devel/kde/kdecvs/kdelibs/kio/kio/kdirwatch.cpp:837
#3  0x404d8f0a in KDirWatchPrivate::checkFAMEvent (this=0x8822d08, fe=0x406041c0)
    at /mnt/devel/kde/kdecvs/kdelibs/kio/kio/kdirwatch.cpp:1032
#4  0x404d87e2 in KDirWatchPrivate::famEventReceived (this=0x8822d08)
    at /mnt/devel/kde/kdecvs/kdelibs/kio/kio/kdirwatch.cpp:945
#5  0x404da443 in KDirWatchPrivate::qt_invoke (this=0x8822d08, _id=3, _o=0xbfffee90) at kdirwatch_p.moc:86

Hmm, I realize I haven't had it for some time, so maybe it's fixed now.

> > > > KDirWatch's debug output will tell you which method you're using (Stat,
> > > > FAM or DNOTIFY). Which one is it?
> > >
> > > [..]
> > > kio (KDirWatch): Can't use FAM (fam daemon not running?)
> > > kio (KDirWatch): Available methods: Stat
> >
> > Do you have 'fam' configured in inetd.conf (or xinetd.d/fam) ?
> > Do you have portmap running? (I found out that it was necessary)
> > I know, this won't help users that don't have FAM, but my interest is in
> > making sure that all systems where FAM should work, are actually configured
> > to make it work (to find out what to tell users and distributors, so that
> > it works for most people).
> 
> If fam is not called from inetd, but from a startup script, there HAS to be 
> the option "-t 0" to not let fam quit after 5 seconds of inactivity (e.g. 
> when logging out of KDE and in again).

I have a machine where FAM works ok (the one with the crash above ;-),
but on the other one, I get the "daemon not running" problem.
FAM _is_ started by xinetd. With no command line arguments at all.
Ah, the syslog message is
xinetd: libwrap refused connection to sgi_fam from <no address>.
Looks like a Mandrake paranoia thingie (but I can't find any libwrap anywhere...)

> This one is not unfixable. Since KDE 3.0, the addDir method has a "watchFiles"
> bool arg. Unfortunately it's still not implemented; 2 weeks ago, there was 
> someone with a patch to make it work - unfortunately not the right one :-(
> But nonetheless: An application wanting to watch the files should set this 
> flag - and the author should implement it. It should be straight forward:

But Konqueror (which needs to notice files growing) would then be stat'ing
every file it's showing? This could be a lot of files. Do we really want that?

- -- 
David FAURE, david at mandrakesoft.com, faure at kde.org
http://people.mandrakesoft.com/~david/
Contributing to: http://www.konqueror.org/, http://www.koffice.org/
Get the latest KOffice - http://download.kde.org/stable/koffice-1.2/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQE9op5372KcVAmwbhARAp71AJ9ckc4zs+DT5PL/z4Knv6QiuLa03gCfaK3h
0x+DyqMN1nalFpKHaSehmf8=
=HPYd
-----END PGP SIGNATURE-----