problem with KIO::NetAccess and KDirLister/KFileTreeView

[Josef Weidendorfer]

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,
together with the unimplemented options for addDir...


On Monday 07 October 2002 18:58, David Faure wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On Monday 07 October 2002 18:41, Klaas Freitag wrote:
> > > If that's the case, then I'd guess KDirWatch got broken. Try "touch
> > > newfile" from a terminal to see if it notices it.
> >
> > Yes, that works with beta 3.1 as well as with 3.0.x. As it also works if
> > I comment out the del-line, I fear that KDirLister deletes the FileItem
> > it just needs to add. Maybe a caching problem? But I am not familiar with
> > KDirLister ;-)
>
> I don't think the problem is in KDirLister. You should see KDirWatch saying
> "hey there's a new file". If you don't see that, then the bug is definitely
> in KDirWatch - or in the way it's being used, maybe.
>
> > 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...

> (Please understand that I'm more familiar with KDirLister and KIO than
> with KDirWatch itself).

Feel free to ask ;-)

> > > 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).

> > Yes ;-) but it is not too easy to escape from it as long as you do not
> > want to implement a lot of its functionality again just to control it ;-)

I would suggest fixing KDirWatch...

> Hmm. But we all know that KDirWatch isn't 100% reliable - the well known
> unfixable case is updating an existing file, in a directory watched with
> the Stat method.

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:

In addDir, create a watch for each file, too. For FAM, the daemon doesn't need 
to be notified about this additional watches: FAM does file watching without 
request ;-) For DNOTIFY, eventually change the directory notification flags 
in the request to the kernel to inform it about needed events for file 
changes (Note: another DirWatch instance in this app could already have 
requested DNOTIFY events for that dir without file watching...).
Finally, check that everything still works if the FAM daemon happens to 
crash/terminate/being killed at some arbitrary time: Switch to Stat watching 
then.
Note: Even for FAM we need to create the file watches to allow for working
fail-back to STAT and - more important - keep pending events when watching
is temporary stopped.

Finally we need to remember the original watch (To delete/start/stop the file 
watches when the dir watch is deleted/scanning started/stopped). When file 
addition/deletion for the dir is detected, a watch has to be set/removed on 
the file in question automatically.

And there's the "recursive" flag in addDir, too: Its a little bit more 
complicated... :-)

Josef

>
> - --
> 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)
>
> iD8DBQE9ob1H72KcVAmwbhARAk4xAJ9LPK/xhNdi3OZUYdn3zLv7qtPjPQCeOg1o
> UYBqCrKh8M7s3OLC6zes0r0=
> =3EkG
> -----END PGP SIGNATURE-----