problem with KIO::NetAccess and KDirLister/KFileTreeView

[Klaas Freitag]

On Tue, 8 Oct 2002, David Faure wrote:

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

Hmmm. Investigation is the wrong word here, but I can attach a file showing the
context of start- and stop scanning, renaming starts at line 627 to see in the
logfile.  For me it seems as if the delete event arrives first and makes
KDirWatch stop scanning (line 645) with stopDirScan. The following backtrace in
the log is printed in the next line of kdirwatch. The restart follows
immediately by restartEntryScanDir. For me, the log shows that the 'here is a
new file' signal does not appear. Hmmm. I hope you see what happens :-)

Klaas

>

-- 
 Was auch immer geschieht :                                Klaas Freitag
 Nie dürft ihr so tief sinken,                      mail freitag at suse.de
 von dem Kakao, durch den man euch zieht,           SuSE Labs, Nuernberg
 auch noch zu trinken! - E. Kaestner
-------------- next part --------------
A non-text attachment was scrubbed...
Name: btrace.txt.bz2
Type: application/octet-stream
Size: 7502 bytes
Desc: logfile
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20021008/4eb2814e/attachment.obj>